Installation de l’autorité secondaire n°1 pour les certificats des utilisateurs

I. Présentation

Ce chapitre évoque l'installation et la configuration de la première autorité secondaire, destinée à délivrer les certificats aux utilisateurs.

Précédemment, nous avons déployé l'autorité racine. Il est temps à présent d'implémenter notre première autorité intermédiaire. Ce serveur nommé S-SUBCA1 est intégré au domaine Active Directory, ce sera une CA d'entreprise.

Les chapitres suivants décrivent l'installation et la configuration de l'autorité.

II. Déploiement de l'autorité secondaire

A. Ajout du rôle AD CS

La première étape consiste à ajouter le rôle d’autorité de certification sur la machine depuis le Gestionnaire de serveur. Cliquez sur "Ajouter des rôles et des fonctionnalités".

Appuyez sur « Suivant » plusieurs fois pour atteindre l’écran de sélection du rôle. Choisissez le rôle "Service de certificats Active Directory" dans la liste et validez l'écran associé d'ajout des fonctionnalités requises en cliquant sur le bouton "Ajouter des fonctionnalités".

Passez l'écran des fonctionnalités sans rien changer et cliquez sur "Suivant" pour parvenir à l'écran de sélection des services de rôle. Cochez la case devant "Autorité de certification" uniquement.

Cliquez alors sur le bouton "Suivant", puis sur "Installer". Une fois l'installation terminée, vous ne devez pas cliquer tout de suite sur le lien "Configurer les services de certificats…", une étape doit être réalisée au préalable. Poursuivez donc la lecture de ce chapitre.

B. Stratégie AD CS

Juste après l'installation du rôle, et avant sa configuration, vous devez créer un fichier nommé CAPolicy.inf, comme nous l'avons fait précédemment pour l'autorité racine. À partir du Bloc-notes, créez ce fichier sous "C:\Windows" afin de fixer certains paramètres avant même le premier démarrage du service comme :

• Empêcher la publication des modèles de certificats par défaut,
• Définir la longueur de clé privée de l'autorité lors de son renouvellement,
• Fixer la durée de validité de la CRL.

Pour une autorité intermédiaire, voici les paramètres que j'ai l'habitude d'utiliser :

[Version]
Signature="$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=3072
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=0
CRLPeriod=weeks
CRLPeriodUnits=2

Tous les paramètres sont expliqués dans cette documentation. Toutefois, voici des indications sur les plus paramètres les plus importants que nous venons de déclarer :

• RenewalKeyLength : indique que la longueur de clé privée passera à 4096bits, lors du renouvellement du certificat d'autorité et de sa clé privée.
• RenewalValidityPeriod/Units : précise que la durée de validité du certificat lors de son renouvellement sera de 10 ans.
• AlternateSignatureAlgorithm : permet d'utiliser un algorithme de signature plus ancien issu du premier standard PKCS#1 V2.1
• LoadDefaultTemplates=0 : empêche la publication de tous les modèles par défaut, évitant l'émission non souhaitée de certificats sur des machines du domaine.

Enregistrez le fichier et passez à la suite.

C. Configuration initiale

À présent, il est possible de terminer l'assistant de configuration. Depuis le Gestionnaire de serveur, cliquez sur le lien "Configurer les services de certificats…".

Étant connecté avec un compte administrateur du domaine, cliquez simplement sur "Suivant".

Cochez la case devant l'intitulé « Autorité de certification ». Il peut se passer plus d'une minute avant que le bouton "Suivant" apparaisse.

S'agissant d'un serveur intégré au domaine Active Directory, les options d'autorité de type entreprise (Enterprise) ou autonome (Standalone) sont disponibles. Ici, nous choisirons de construire une autorité de type Enterprise. Le choix fait, cliquez sur le bouton "Suivant".

Ici, il suffit logiquement de choisir "Autorité de certification secondaire".

S'agissant d'une toute nouvelle autorité, il nous faut créer une nouvelle clé privée qui sera stockée localement sous Windows. Dans le cas de l'utilisation d'un HSM (voir le module de ce cours dédié à la sécurité d'AD CS), il est possible à ce stade de choisir l'emplacement correspondant au module de sécurité.

Plusieurs sélections à faire sur cet écran :

• La longueur de la clé privée de l'autorité : 2048 bits est le minimum, 3072 bits est un plus en matière de sécurité
• L'algorithme de hachage pour l'émission des certificats : SHA256 est le bon choix pour une autorité intermédiaire
• L'option "Autorisez l'interaction de l'administrateur lorsque l'autorité de certification accède à la clé privée" est utile avec un module HSM (voir le chapitre de ce cours dédié à ce sujet pour plus d'informations), l'administrateur devant parfois entrer un mot de passe pour autoriser l'accès à la clé privée. Sans module HSM, ici la case reste décochée.

L'écran suivant présente les noms liés à l'autorité. Il s'agit d'informations que l'on retrouvera typiquement dans les certificats issus de cette autorité. Il ne faut pas laisser les valeurs par défaut, et ce, pour plusieurs raisons :

1. Le nom du serveur apparait dans le nom convivial, mais lors d'une migration vers une nouvelle machine, souvent avec un nom différent, il ne sera pas possible de le changer, d'où une incohérence,
2. Divulguer le nom du serveur donne trop d'indications inutilement, et ce n'est pas idéal en termes de sécurité,
3. Les informations minimales (organisation…) ne sont pas fournies dans le certificat, aussi il pourrait être considéré invalide par certains navigateurs.

Pour toutes les raisons évoquées précédemment, une syntaxe telle qu'illustrée ci-dessous sera beaucoup plus pertinente :

À ce stade, il convient d'envoyer une demande de certificat auprès de l'autorité racine. Si cette dernière était intégrée à l'Active Directory, il serait possible de faire une demande en ligne. En revanche, puisque nous disposons d'une autorité autonome, il faut passer par un fichier de demande (.req, aussi appelé .csr). Le fichier est enregistré à la racine du disque système et il faut le copier vers l'autorité racine.

Concernant l'emplacement de la base de données et des journaux de transaction de l'autorité, il faut savoir que les bonnes pratiques Microsoft indiquent de les positionner sur un disque à part. La raison évoquée parle d'accès fréquents et simultanés. Objectivement, sauf à émettre des certificats par centaine toutes les minutes, ça ne sera pas nécessaire, aussi vous pouvez conserver un hébergement sur le disque système avec les chemins par défaut.

Tout est prêt, il ne reste plus qu'à cliquer sur le bouton "Configurer".

Quelques secondes plus tard, vous obtiendrez un message de réussite avec un avertissement ! En effet, pour finaliser la configuration, il faut soumettre la demande de certificat auprès de l'autorité racine, puis récupérer la réponse et installer le certificat obtenu sur l'autorité secondaire.

D. Finalisation

Une fois le fichier de requête copié sur l'autorité racine, il est possible de demander le certificat. Depuis la console de gestion de l'autorité racine, opérez un clic-droit sur le nom de l'autorité, et à la rubrique Toutes les tâches, vous trouverez l'option "Soumettre une nouvelle demande…"

Vous pourrez alors sélectionner le fichier de demande.

Aucun message ne s'affiche. Rendez-vous à la rubrique "Demandes en attente", où vous verrez apparaître la demande envoyée. En faisant un clic-droit dessus, vous pourrez accéder à "Toutes les tâches" -> "Délivrer".

Cette fois, c'est depuis la rubrique « Certificats délivrés » que l'on retrouvera notre tout nouveau certificat et il nous faut l'exporter afin de l'installer sur l'autorité secondaire. Opérez un double-clic sur l'entrée du certificat dans la liste de la vue "Certificats délivrés", puis dans l'onglet "Détails", cliquez sur le bouton "Copier dans un fichier". Le fichier généré devra être copié sur le serveur d'autorité intermédiaire.

De retour sur l'autorité intermédiaire, il nous reste à installer le certificat d'autorité provenant de l'autorité racine. Faites un clic-droit sur le nom de l'autorité, puis "Toutes les tâches" et "Installer un certificat d'autorité de certification".

Dans la fenêtre de sélection, changez le type de fichier pour "*.cer", puis sélectionnez le fichier de certificat. Pour mémoire, la clé privée est générée lors de la demande de certificat et elle est stockée en local sur cette machine d'autorité intermédiaire. En important le certificat, on rattache la clé privée au certificat.

Cliquez alors sur le bouton pour démarrer le service AD CS.

Si l'avertissement suivant s'affiche, c'est que le serveur ne parvient pas à vérifier la révocation du certificat délivré par l'autorité racine. Vérifiez que le nom DNS « pki.contoso.com », dans mon exemple, peut être résolu et que le fichier de CRL existe bien sur le serveur « S-SERVICESCA ».

Au final, vous devriez obtenir un affichage équivalent à celui-ci :

III. Tâches post-installation

A. Durée de validité

Par défaut, les certificats émis par l'autorité sont valables 2 ans. Cette durée peut convenir, toutefois sur certaines plateformes où le changement de certificats est pénible, une durée plus longue sera profitable. Raisonnablement, il est possible de l'étendre à 3 ans.

Depuis une invite de commandes PowerShell, exécuter :

Certutil -setreg CA\ValidityPeriodUnits 3
Certutil -setreg CA\ValidityPeriod "Years"
Restart-Service certsvc

Comme lors de la préparation de l'autorité racine, ces commandes viennent ajuster la configuration de la machine au niveau du Registre de Windows (sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\).

B. CRL : Delta

La liste de révocation de certificats (CRL) est valable 2 semaines comme nous l'avons paramétré précédemment. Elle sera utilisée pour vérifier la révocation des certificats émis par cette autorité.

Par défaut, une liste de révocation delta est générée chaque jour en plus de la liste complète. Sauf à avoir un usage intensif, la liste de révocation delta n'est pas utile et elle peut être désactivée.

C. CRL : Emplacements

La CRL est publiée à la fois dans l'Active Directory, puisqu'il s'agit d'une autorité de type « Enterprise », et en local sous « C:\Windows\System32\Certsrv ».

Depuis la console de gestion de l'autorité, on voit plusieurs emplacements pré-renseignés et des cases « Publier » ou « Inclure », certaines grisées, d'autres non.

Pour rappel :

• Publier : indique de générer le fichier à cet emplacement,
• Inclure : référence ce chemin dans tous les certificats émis par l'autorité, de sorte qu'un client qui se voit présenter un certificat et veut en vérifier sa révocation sache à quel endroit se référer. Pour que l'option soit accessible, il doit s'agir d'un chemin réseau de type UNC, LDAP, ou Web, commençant donc par \\, ldap ou http.

Dans notre architecture, un serveur est utilisé pour la publication des CRL. Nous allons par conséquent ajouter l'information dans les extensions, à la fois pour publier les fichiers et également pour inclure le chemin. Voici comment :

1. Cliquer sur le bouton "Ajouter",
2. Taper le début de l'adresse (alias) du serveur CRL
3. Dans la liste déroulante des "variables", sélectionner <NomAutoritéCertification> puis,
4. Cliquer sur "Insérer".

Note : le répertoire virtuel CRLdist n'existe pas encore, mais pas d'inquiétudes, on s'en occupe tout de suite après.

Insérez une autre variable pour refléter la liste de révocation et terminez en tapant ".crl" pour l'extension du fichier.

Il ne reste plus qu'à cocher la case "Inclure dans l'extension CDP…"

À présent, si on veut que le fichier .crl soit automatiquement copié vers l'emplacement que l'on vient d'ajouter, "pki.office.com" alias "S-SERVICESCA", il nous faut ajouter un chemin UNC :

1. Cliquez sur le bouton "Ajouter",
2. Tapez le chemin UNC, ici : \\S-SERVICESCA\CRLdist.

À noter : la syntaxe file://\\ S-SERVICESCA\CRLdist est possible également.

1. Dans la liste déroulante des "variables", sélectionnez <NomAutoritéCertification> puis cliquez sur "Insérer",
2. Dans la liste déroulante des "variables", sélectionnez < SuffixeNomListeRévocationCertificats> puis cliquez sur "Insérer",
3. Ajoutez, au bout de la ligne, ".crl."
4. Validez par "OK".

Il ne reste plus qu'à cocher la case "Publier les listes de révocation des certificats à cet emplacement".

Validez par OK la fenêtre, un redémarrage du service de l'autorité vous sera demandé. Cliquez sur le bouton "Oui".

D. CRL : Points de distribution

Nous avons référencé le serveur S-SERVICESCA dans les extensions de l'autorité. À présent, il nous faut ajouter depuis ce serveur S-SERVICESCA les points de distribution, à commencer par un dossier avec un partage de fichiers.

Ouvrez "l'Explorateur de fichiers" et créez un dossier nommé "CRLdist", par exemple.

Partagez le dossier avec le même nom de partage.

Pour les autorisations, il convient d'ajouter le compte ordinateur de l'autorité intermédiaire. Cliquez sur le bouton "Ajouter…", dans les types d'objets, cochez "des ordinateurs", et entrez le nom du serveur.

Donnez alors le droit « Contrôle total ».

Validez par "OK", puis "fermer".

Autre point de distribution, l'ajout d'un répertoire virtuel IIS. Lancer la console "Gestionnaire des services Internet (IIS)" sur le serveur.

Ajoutons tout d'abord un répertoire virtuel :

Précisez le nom et le chemin, avant de valider par "OK".

Deux options doivent être personnalisées :

1. Activez l'exploration de répertoires (Directory Browsing).

Cliquez alors sur le bouton "Activer".

2. Retournez sur la page d'accueil du répertoire virtuel et lancez "l'éditeur de configuration".

À la rubrique « system.webServer\security\requestFiltering », changez l'option "AllowDoubleEscaping" pour la passer à "True", puis cliquez sur "Appliquer".

Cette option autorise l'utilisation de caractères spéciaux dans l'URL et donc de fichiers de CRL delta qui contiennent un '+' dans leur nom.

Dernière chose à faire, publier une nouvelle CRL pour alimenter le serveur « S-SERVICESCA ». De retour sur la console de gestion de l'autorité, positionnez-vous à la rubrique "Certificats révoqués", puis "Toutes les tâches", et enfin "Publier".

Acceptez le seul choix possible et validez par "OK".

Vérifiez votre travail en confirmant que le fichier de CRL a été copié automatiquement dans le partage.

IV. Conclusion

Notre première autorité intermédiaire est à présent fonctionnelle. Il nous reste à déployer la seconde autorité intermédiaire, S-SUBCA2, puis à configurer les services additionnels sur S-SERVICESCA. Direction le prochain chapitre pour continuer la mise en œuvre de cette PKI !