Installation de l’autorité racine AD CS

I. Présentation

Ce chapitre évoque l'installation de l'autorité racine, en tant que CA autonome, afin de monter le premier niveau de l'architecture décrite en introduction, à savoir une PKI à deux niveaux.

Concrètement, ce serveur nommé S-ROOTCA restera en Workgroup (donc il n'est pas intégré au domaine Active Directory). De plus, il sera, par ailleurs, éteint à la fin de l'implémentation des autres autorités de certification.

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

Remarque : la procédure décrite dans cet article est valide avec Windows Server 2022 et Windows Server 2025.

II. Déploiement du rôle AD CS

A. Ajout du rôle

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 "Service de certificats Active Directory" 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, ne cliquez pas tout de suite sur le lien "Configurer les services de certificats…", une étape doit être réalisée au préalable.

B. Stratégie AD CS

Juste après l'installation du rôle, et avant sa configuration, un fichier nommé CAPolicy.inf peut être créé, via bloc-notes, 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é racine, j'utilise habituellement, le fichier suivant :

[Version]
Signature="$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10
AlternateSignatureAlgorithm=0
CRLPeriod=years
CRLPeriodUnits=1

Tous les paramètres sont expliqués dans cette documentation, toutefois voici des indications sur les plus importants :

• 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

C. Configuration initiale

A 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…"

Etant connecté avec un compte administrateur local, 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 en workgroup, seul le choix "Autorité de certification autonome" (Standalone CA) est disponible. Une autorité de type "Enterprise" nécessite que la machine soit intégrée au domaine Active Directory.

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

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 dédié à la sécurité de ce cours pour plus d'explications), 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, 4096 bits est un plus en matière de sécurité
• L'algorithme de hachage pour l'émission des certificats : SHA256 est le minimum, SHA512 est un choix raisonnable pour une autorité racine
• 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 rubrique sur la Sécurité dans ce cours pour plus d'explications), 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é. Si j'ai barré les infos, c'est pour marquer le fait qu'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 :

Indiquer ensuite la durée de validité de la clé privée :

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.

D. Vérifications

Lancez la console MMC "Autorité de certification", à présent disponible dans les outils d'administration.

Depuis les propriétés de la rubrique "Certificats révoqués", observez que la durée de validité de la CRL est bien de 1 an comme défini dans le fichier CAPolicy.inf.

III. Tâches post-installation

A. Publication de la CA dans l'Active Directory

Bien que cette autorité autonome ne fasse pas partie du domaine, les CRL Distribution Points (CDP) et les emplacements Authority Information Access (AIA), vont être stockés dans l'Active Directory. Elle doit disposer des informations du domaine pour permettre une publication correcte.

Exécutez la commande suivante (en adaptant le DistinguishedName pour qu’il corresponde à votre domaine) :

certutil.exe -setreg ca\DSConfigDN CN=Configuration,DC=contoso,DC=ad

Le certificat de l'autorité (sans sa clé privée) peut être désormais intégré à l'Active Directory. Cela aura pour effet de le pousser automatiquement sur toutes les machines du domaine. Une fois cette configuration établie, il ne sera pas nécessaire de le pousser en plus par GPO, comme je le vois souvent. Rien de grave si c'est le cas, néanmoins il sera présent en doublon sur les postes et serveurs du domaine.

La première étape consiste à exporter le certificat d'autorité. Depuis la console MMC "Autorité de certification", appelez les propriétés sur le nom de l'autorité. Vous pourrez alors "Afficher le certificat" et le "Copier dans un fichier…"

Sur le format d'export, choisissez Base64. Le format DER est lu, lui aussi,mpris par Windows, mais l'encodage en Base64 présente deux avantages principaux :

1. Il est human-readable, cela signifie qu'en ouvrant le fichier avec un éditeur de texte, vous pourrez lire la structure qui commence généralement par ---BEGIN CERTIFICATE---
2. C'est un format PEM compris par des machines Linux

Cliquez alors sur "Suivant". Un emplacement et un nom de fichier vous seront demandés.

Terminez l'assistant jusqu'au bout.

Copiez ce fichier sur un serveur membre du domaine ou sur un contrôleur de domaine. Puis lancez la commande suivante depuis une invite :

certutil -dspublish -f C:\certificats\ContosoRootCA-cert.cer RootCA

Note : le nom RootCA n'est pas le nom de l'autorité, mais l'indication du container où intégrer le certificat.

Le résultat doit être similaire à celui-ci :

Il est même possible de retrouver le certificat publié, en ouvrant la console "Sites et Services Active Directory". Dans le menu « Affichage », veillez à cocher "Afficher les nœuds des services". Vous pourrez observer la présence du certificat dans le conteneur "Certification Authorities".

B. Durée de validité

Par défaut, les certificats émis par l'autorité sont valables 2 ans. Puisque nous allons demander, peu plus tard, un certificat pour la première autorité intermédiaire qui devra être valable 5 ans, nous devons étendre cette durée.

Depuis une invite de commandes PowerShell, exécutez ces commandes :

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

Note : la commande modifie des entrées de registre qui sont présentes sous "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\".

C. CRL

La liste de révocation de certificats (CRL) est valable 1 an 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é.

Toutefois, cette CRL n'est mise à disposition qu'en local, sur l'autorité racine. Pour le vérifier, il suffit de prendre les propriétés de l'autorité depuis la console de gestion de l'autorité de certification, à la rubrique « Extensions », puis « CDP ». On constate un chemin local sous « C:\Windows\System32 ». Allons voir de plus près :

Le fichier de CRL est bien présent, de même que le certificat de l'autorité.

De retour sur 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.

L'explication est la suivante :

• 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. Voici comment :

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

Insérez une autre variable, SuffixeNom… 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…".

Pour l'emplacement « file:// », vous pouvez aller décocher les deux cases "Inclure", elles ne nous seront pas utiles.

Enfin, en validant par OK la fenêtre, un redémarrage du service de l'autorité vous sera demandé. Cliquez sur le bouton « Oui ».

Dernière étape : copier le fichier de CRL vers le serveur « SERVICESCA » de notre architecture.

Vous pouvez le récupérer sous « C:\Windows\System32\CertSrv\CertEnroll ».

Copier également le fichier de certificat portant l'extension .crt, il nous sera utile un peu après.

Si le dossier « wwwroot » n'existe pas à la cible, vérifiez que vous avez bien suivi l'installation du prérequis IIS mentionné au paragraphe d'introduction.

D. AIA

Toujours depuis l'onglet Extensions, choisissez AIA dans la liste déroulante. Il nous faut à présent retirer le chemin "file" qui ne sera pas joignable, car il fait référence à l'autorité racine qui sera éteinte ensuite.

Nous allons le remplacer par un emplacement http vers notre serveur SERVICES-CA qui lui restera joignable.

http://pki.contoso.com/<Nom du serveur DNS>_<NomAutoritéCertification><NomCertificat>.crt

Pour terminer, cocher la case "Inclure dans l'extension AIA des certificats émis".

IV. Conclusion

À présent que notre autorité de certification racine est installée et configurée, nous allons pouvoir déployer une première autorité intermédiaire. Vous découvrirez comment dans le prochain chapitre.