AD CS : une autorité de certification d'entreprise

AD CS (Active Directory Certificate Services, services de certificats Active Directory) est le rôle de Windows Server qui transforme un serveur en autorité de certification (AC) : il délivre, renouvelle et révoque les certificats électroniques des utilisateurs, des ordinateurs et des services de l'organisation, en s'appuyant sur l'annuaire. Ce chapitre explique à quoi sert une autorité interne, comment organiser sa hiérarchie, l'installer, publier des modèles de certificats, distribuer les certificats automatiquement par GPO, gérer la révocation et protéger l'autorité. Le fonctionnement des certificats et de la PKI (clés, signature, chaîne de confiance) est expliqué dans le chapitre Certificat électronique et PKI du cours Cryptographie.

À quoi sert une autorité de certification interne

Dans un réseau d'entreprise, beaucoup de services ont besoin d'un certificat :

Pourquoi pas une autorité publique ? Les autorités publiques ne délivrent plus de certificats pour des noms internes (ad.sorbier.example non publié, srv-ad, une adresse IP privée), chaque certificat a un coût et une durée de validité de plus en plus courte, et l'on ne maîtrise ni les modèles ni la révocation. Une autorité interne, elle, n'est reconnue que par les machines qui lui font confiance : c'est suffisant pour les postes et serveurs du domaine, qui reçoivent son certificat racine automatiquement, mais pas pour un site web public, qui garde un certificat d'une autorité publique.

Racine, autorité secondaire, entreprise ou autonome

Une PKI est une hiérarchie : l'autorité racine signe le certificat d'une ou plusieurs autorités secondaires (ou intermédiaires), qui signent les certificats des utilisateurs, des machines et des services. Un client fait confiance au certificat d'un serveur s'il remonte la chaîne jusqu'à une racine présente dans son magasin des autorités de certification racines de confiance.

AD CS propose deux types d'autorités :

La hiérarchie recommandée, à deux niveaux :

1. une AC racine autonome hors ligne : un serveur (souvent une machine virtuelle) qui n'est pas membre du domaine, éteint et débranché du réseau la plupart du temps. Il ne sert qu'à signer le certificat de l'autorité secondaire (pour 10 ans, par exemple) et à publier sa liste de révocation (une fois par an, par exemple). Sa clé privée ne court ainsi presque aucun risque ;
2. une AC secondaire d'entreprise, en ligne, membre du domaine, qui délivre tous les certificats.

Une petite structure se contente parfois d'une seule AC racine d'entreprise en ligne. C'est plus simple, mais sa compromission oblige à reconstruire toute la PKI : à documenter comme un risque accepté.

Installer une autorité de certification d'entreprise

L'autorité de certification est une ressource du tier 0 (chapitre 13) : celui qui la contrôle peut délivrer un certificat d'authentification au nom de n'importe quel compte, administrateurs du domaine compris. On l'installe sur un serveur dédié, protégé comme un contrôleur de domaine, et on ne change ni son nom ni son appartenance au domaine après l'installation.

# Le rôle et la console
Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

# Une AC racine d'entreprise (cas simple, à un niveau) : clé RSA 4096, SHA-256, 10 ans
Install-AdcsCertificationAuthority -CAType EnterpriseRootCA -CACommonName "Sorbier-AC" `
    -KeyLength 4096 -HashAlgorithmName SHA256 -ValidityPeriod Years -ValidityPeriodUnits 10

Pour une autorité secondaire d'entreprise, on utilise -CAType EnterpriseSubordinateCA : l'installation produit une demande de certificat qu'on porte (sur un support amovible) jusqu'à l'AC racine hors ligne, qui la signe ; on installe ensuite le certificat signé sur l'autorité secondaire.

Les consoles : Autorité de certification (certsrv.msc) pour gérer l'autorité, les certificats délivrés et révoqués ; Modèles de certificats (certtmpl.msc) ; Certificats - ordinateur local (certlm.msc) sur chaque machine, pour voir ses certificats.

Une autorité d'entreprise publie son certificat dans l'annuaire : tous les membres du domaine lui font automatiquement confiance, sans rien installer sur les postes.

Les modèles de certificats

Un modèle définit ce que sera un certificat : son usage (authentification du serveur, du client, signature de code), sa durée de validité, la longueur de la clé, la façon dont le nom du sujet est construit, et qui a le droit de le demander. Windows fournit des modèles par défaut (Ordinateur, Utilisateur, Serveur Web, Contrôleur de domaine, Authentification Kerberos…).

La méthode :

1. dans certtmpl.msc, dupliquer un modèle proche (ne modifie pas les modèles d'origine) : par exemple Serveur Web devient Sorbier - Serveur Web ;
2. régler la durée de validité, la longueur de la clé et, dans l'onglet Nom du sujet, la façon dont le nom est fourni ;
3. dans l'onglet Sécurité, donner Lecture et Inscrire (et Inscription automatique si besoin) au groupe concerné, par exemple GG_Serveurs_Web ;
4. dans certsrv.msc, publier le modèle sur l'autorité : Modèles de certificats > Nouveau > Modèle de certificat à délivrer.

L'inscription automatique par GPO

Pour que les ordinateurs ou les utilisateurs obtiennent et renouvellent seuls leur certificat, on active l'inscription automatique :

1. sur le modèle, donner Lecture, Inscrire et Inscription automatique au groupe concerné (par exemple Ordinateurs du domaine pour le modèle Ordinateur, utilisé par 802.1X) ;
2. dans une GPO liée aux OU concernées : Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies de clé publique > Client des services de certificats - Inscription automatique : Activé, avec Renouveler les certificats expirés, mettre à jour les certificats en attente et supprimer les certificats révoqués et Mettre à jour les certificats qui utilisent les modèles de certificats cochés (la même stratégie existe en configuration utilisateur pour les certificats d'utilisateurs).

# Sur un poste : déclencher l'inscription automatique sans attendre
certutil -pulse

# Voir les certificats de l'ordinateur et leur date d'expiration
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, NotAfter, Issuer

# Demander un certificat à partir d'un modèle publié (nom interne du modèle)
Get-Certificate -Template "SorbierServeurWeb" -DnsName "intranet.ad.sorbier.example" -CertStoreLocation Cert:\LocalMachine\My

Les contrôleurs de domaine obtiennent automatiquement un certificat dès qu'une AC d'entreprise existe : c'est ce qui active LDAPS sur le port 636, sans autre configuration.

La révocation : CRL et OCSP

Un certificat dont la clé a été volée, ou délivré par erreur, doit être révoqué avant son expiration : dans certsrv.msc, Certificats délivrés > clic droit > Toutes les tâches > Révoquer le certificat, avec un motif.

Les clients apprennent la révocation par deux moyens :

• la liste de révocation de certificats (CRL), publiée régulièrement par l'autorité (chaque semaine par défaut, avec des CRL delta plus fréquentes), aux emplacements inscrits dans chaque certificat : les points de distribution de CRL (CDP), un chemin LDAP dans l'annuaire et une adresse HTTP ;
• le répondeur en ligne (OCSP, service de rôle ADCS-Online-Cert), qui répond pour un certificat précis sans télécharger toute la liste.

Protéger et sauvegarder l'autorité

• La clé privée de l'autorité est le bien le plus précieux de la PKI : protégée par un module matériel de sécurité (HSM) dans les grandes organisations, au minimum par l'accès restreint au serveur et le chiffrement de ses sauvegardes.
• Sauvegarder régulièrement la clé, le certificat et la base de l'autorité : Backup-CARoleService -Path "D:\Sauvegardes\AC" -Password (Read-Host -AsSecureString), ou certutil -backup. Sans sauvegarde, la perte du serveur oblige à reconstruire toute la PKI et à redéployer tous les certificats.
• Auditer l'autorité (demandes, délivrances, révocations, modifications de modèles) et collecter ces événements (chapitre 14).
• Réviser régulièrement les modèles publiés et leurs autorisations d'inscription.

Exercices