AD CS : déployer une PKI d'entreprise avec Root CA offline et CA émettrice

Une infrastructure PKI (Public Key Infrastructure) interne constitue le socle de confiance numérique de toute organisation utilisant Active Directory. Elle permet d'émettre des certificats TLS pour sécuriser les communications internes, d'authentifier les postes et les utilisateurs via des certificats machine ou smart card, de signer numériquement des scripts et des e-mails, et de chiffrer des données sensibles. Sans PKI interne, les équipes IT doivent recourir à des certificats auto-signés que les navigateurs rejettent, ou dépenser des budgets conséquents en certificats publics pour des usages purement internes. Active Directory Certificate Services (AD CS), le rôle Windows Server dédié à la PKI, offre une solution robuste et intégrée à l'écosystème Microsoft. Ce guide vous accompagne pas à pas dans la conception et le déploiement d'une PKI d'entreprise à deux niveaux : une Root CA maintenue hors ligne pour une sécurité maximale, et une Issuing CA en ligne intégrée à l'Active Directory pour l'émission quotidienne de certificats. Vous apprendrez à publier votre chaîne de confiance via GPO, à créer des modèles de certificats adaptés à vos besoins, à configurer l'auto-enrollment pour automatiser la distribution, et à gérer le cycle de vie complet des certificats, de l'émission à la révocation.

Architecture PKI deux niveaux : Root CA offline et CA émettrice

La conception en deux niveaux est la référence pour les PKI d'entreprise. Elle repose sur un principe simple : séparer la clé privée racine, extrêmement précieuse, de l'autorité quotidiennement exposée sur le réseau.

La Root CA (autorité de certification racine) constitue l'ancre de confiance absolue de votre PKI. Sa clé privée doit être protégée à tout prix. Pour cela, on l'installe sur un serveur dédié qui n'est connecté à aucun réseau — ni corporate, ni Internet. Ce serveur est démarré uniquement lors d'opérations rares : signer le certificat de la CA subordonnée, renouveler son propre certificat (tous les 10-20 ans), ou publier une nouvelle CRL. Entre ces opérations, la machine est physiquement éteinte et stockée dans un lieu sécurisé (coffre, datacenter avec contrôle d'accès). La clé privée doit également être sauvegardée sur un support chiffré hors site.

La Subordinate CA ou Issuing CA (CA émettrice) est signée par la Root CA et hérite de sa confiance. Elle est connectée au réseau d'entreprise et intégrée à l'Active Directory. C'est elle qui émettrait tous les certificats du quotidien : certificats machine, utilisateur, serveur web, etc. Si cette CA est compromise, vous pouvez la révoquer depuis la Root CA et en déployer une nouvelle sans reconstruire l'ensemble de la PKI.

Cette séparation garantit que même en cas de compromission totale de la CA émettrice, l'ancre de confiance reste intacte. La durée de vie typique d'un certificat Root CA est de 20 ans, celle d'une Subordinate CA de 10 ans, et celle des certificats finaux de 1 à 3 ans.

Pour un environnement de production, prévoyez également une Subordinate CA de secours (même configuration, maintenue éteinte) pour assurer la continuité en cas de panne matérielle de la CA principale.

Installer et configurer la Root CA offline (Windows Server Core, déconnecté)

L'installation de la Root CA s'effectue sur une machine Windows Server jamais connectée au réseau d'entreprise. Windows Server Core (sans interface graphique) est recommandé pour réduire la surface d'attaque.

Sur le serveur Root CA (hors ligne), ouvrez PowerShell et installez le rôle AD CS :

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

Configurez ensuite la Root CA en tant que CA autonome (Standalone) — pas d'intégration AD à ce stade :

Install-AdcsCertificationAuthority `
  -CAType StandaloneRootCA `
  -CACommonName "AyiNedjimi Root CA" `
  -CADistinguishedNameSuffix "DC=ayinedjimi,DC=fr" `
  -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
  -KeyLength 4096 `
  -HashAlgorithmName SHA256 `
  -ValidityPeriod Years `
  -ValidityPeriodUnits 20 `
  -Force

Après installation, configurez les extensions AIA (Authority Information Access) et CDP (CRL Distribution Point) pour pointer vers les URL où la CA émettrice publiera les informations. Ces URL doivent être accessibles depuis le réseau d'entreprise :

# Supprimer les CDP/AIA par défaut
$crlList = Get-CACrlDistributionPoint
foreach ($crl in $crlList) { Remove-CACrlDistributionPoint $crl.Uri -Force }

# Ajouter les CDP
Add-CACrlDistributionPoint `
  -Uri "http://pki.ayinedjimi.fr/pki/AyiNedjimiRootCA.crl" `
  -AddToCertificateCdp -Force

# AIA
$aiaList = Get-CAAuthorityInformationAccess
foreach ($aia in $aiaList) { Remove-CAAuthorityInformationAccess $aia.Uri -Force }

Add-CAAuthorityInformationAccess `
  -Uri "http://pki.ayinedjimi.fr/pki/AyiNedjimiRootCA.crt" `
  -AddToCertificateAia -Force

Publiez la CRL initiale :

certutil -crl

Copiez le certificat Root CA et la CRL sur une clé USB pour les transférer vers la CA émettrice :

Copy-Item "C:\Windows\System32\CertSrv\CertEnroll\*" E:\

Installer la Subordinate/Issuing CA en ligne (intégrée à l'Active Directory)

La CA émettrice s'installe sur un serveur Windows Server membre du domaine Active Directory. Ce serveur doit être stable, sauvegardé régulièrement, et sa disponibilité est critique pour l'ensemble des opérations de certification.

Installez le rôle AD CS :

Install-WindowsFeature ADCS-Cert-Authority, ADCS-Web-Enrollment `
  -IncludeManagementTools

Configurez la CA en tant que Enterprise Subordinate CA (intégrée à l'AD) :

Install-AdcsCertificationAuthority `
  -CAType EnterpriseSubordinateCA `
  -CACommonName "AyiNedjimi Issuing CA 01" `
  -CADistinguishedNameSuffix "DC=ayinedjimi,DC=fr" `
  -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
  -KeyLength 2048 `
  -HashAlgorithmName SHA256 `
  -OutputCertRequestFile "C:\CARequest\SubCA.req" `
  -Force

Cette commande génère un fichier de requête (.req). Copiez ce fichier sur une clé USB et transférez-le vers la Root CA offline. Sur la Root CA, soumettez et approuvez la requête :

# Sur la Root CA
certreq -submit -config "RootCA\AyiNedjimi Root CA" C:\SubCA.req C:\SubCA.crt

# Approbation manuelle
certutil -resubmit [RequestID]

# Récupération
certreq -retrieve -config "RootCA\AyiNedjimi Root CA" [RequestID] C:\SubCA.crt

Transférez SubCA.crt et RootCA.crt vers la CA émettrice et installez le certificat :

# Installer le cert Root dans le magasin local
certutil -addstore Root C:\RootCA.crt

# Installer le certificat de la Subordinate CA
certutil -installcert C:\SubCA.crt

# Démarrer le service
Start-Service CertSvc

Publier le certificat Root dans Active Directory (GPO, AIA, CDP)

Pour que tous les postes du domaine fassent confiance à votre PKI, le certificat de la Root CA doit être distribué via la stratégie de groupe (GPO) et publié dans Active Directory.

Sur un contrôleur de domaine ou depuis la CA émettrice, publiez le certificat Root dans l'AD :

certutil -dspublish -f C:\RootCA.crt RootCA

Créez ensuite une GPO pour distribuer le certificat Root à tous les postes. Dans la Console de Gestion des Stratégies de Groupe (GPMC) :

1. Créez une nouvelle GPO liée au domaine : "PKI – Certificats de Confiance"
2. Naviguez vers : Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities
3. Cliquez droit → Import → sélectionnez RootCA.crt
4. Appliquez la GPO à l'ensemble du domaine

Pour le CDP, créez un partage web sur un serveur IIS dédié ou sur la CA émettrice. Configurez un virtual directory dans IIS :

New-WebVirtualDirectory -Site "Default Web Site" `
  -Name "pki" `
  -PhysicalPath "C:\Inetpub\pki"

Copiez les CRL et les certificats dans ce répertoire. Vérifiez l'accessibilité depuis un poste client :

certutil -verify -urlfetch C:\Users\user\Desktop\machine.cer

La commande certutil -f -dspublish C:\SubCA.crt SubCA publie également le certificat de la Subordinate CA dans l'AD pour les clients qui en auraient besoin.

Créer et configurer des modèles de certificats (Machine, Web Server, Utilisateur)

Les modèles de certificats définissent les paramètres des certificats émis : utilisation de la clé, durée de vie, extensions, qui peut en demander. AD CS Enterprise fournit des modèles prédéfinis qu'il est recommandé de dupliquer plutôt que de modifier directement.

Ouvrez la console Certificate Templates (certtmpl.msc) :

Modèle Machine (authentification ordinateur) :

1. Dupliquez le modèle "Computer" → nommez-le "AyiNedjimi Machine v1"
2. Onglet General : validité 2 ans, renouvellement 6 semaines avant expiration
3. Onglet Subject Name : "Build from Active Directory information"
4. Onglet Security : accordez "Enroll" et "Autoenroll" au groupe "Domain Computers"
5. Onglet Extensions : vérifiez que "Client Authentication" et "Server Authentication" sont présents

Modèle Web Server :

1. Dupliquez le modèle "Web Server" → nommez-le "AyiNedjimi Web Server v1"
2. Onglet Subject Name : "Supply in the request" (le demandeur fournit le CN/SAN)
3. Onglet Extensions : Key Usage = Digital Signature, Key Encipherment
4. Onglet Security : accordez "Enroll" au groupe "Web Servers Admins"

Modèle Utilisateur :

1. Dupliquez le modèle "User" → nommez-le "AyiNedjimi User v1"
2. Onglet General : validité 1 an
3. Onglet Security : accordez "Enroll" et "Autoenroll" à "Authenticated Users"
4. Onglet Extensions : incluez "Client Authentication", "Email Protection", "Encrypting File System"

Activez les modèles sur la CA émettrice via la console Certification Authority (certsrv.msc) : clic droit sur "Certificate Templates" → New → Certificate Template to Issue → sélectionnez vos modèles.

Configurer l'auto-enrollment via GPO (certificats automatiques pour postes et serveurs)

L'auto-enrollment est l'une des fonctionnalités les plus puissantes d'AD CS Enterprise : les postes et utilisateurs du domaine reçoivent automatiquement leurs certificats sans intervention manuelle. Cela garantit une couverture totale sans dépendre de la vigilance des administrateurs.

Dans la GPMC, modifiez votre GPO PKI (ou créez-en une dédiée) :

Pour les certificats machine :

Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client – Auto-Enrollment

• Configuration Model : Enabled
• Cochez : "Renew expired certificates, update pending certificates, and remove revoked certificates"
• Cochez : "Update certificates that use certificate templates"

Pour les certificats utilisateur :

User Configuration → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client – Auto-Enrollment

• Même configuration que ci-dessus

Forcez l'application de la GPO et vérifiez :

gpupdate /force

# Vérifier les certificats reçus
certutil -store My
Get-ChildItem Cert:\LocalMachine\My | Select Subject,NotAfter

Les postes contactent la CA émettrice lors du prochain cycle GPO (toutes les 90 minutes par défaut) et reçoivent automatiquement leurs certificats correspondant aux modèles pour lesquels ils ont la permission "Autoenroll".

Pour forcer immédiatement l'enrollment sur un poste :

certreq -enroll -machine "AyiNedjimi Machine v1"

Émettre un certificat manuellement pour un serveur web (IIS, Apache)

Pour un serveur web, l'émission manuelle via le portail Web Enrollment ou via certreq est souvent plus adaptée car elle permet de spécifier précisément les Subject Alternative Names (SAN).

Via le portail Web Enrollment (http://ca-server/certsrv) :

1. Naviguez vers http://ca-emettrice.ayinedjimi.fr/certsrv
2. Cliquez "Request a certificate" → "Advanced certificate request"
3. Sélectionnez le modèle "AyiNedjimi Web Server v1"
4. Renseignez le CN (ex: intranet.ayinedjimi.fr) et les SAN
5. Téléchargez le certificat émis

Via certreq (méthode recommandée pour les SAN) :

Créez un fichier de requête request.inf :

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=intranet.ayinedjimi.fr,O=AyiNedjimi,C=FR"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
HashAlgorithm = SHA256

[RequestAttributes]
CertificateTemplate = "AyiNedjimiWebServerv1"

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=intranet.ayinedjimi.fr&"
_continue_ = "dns=intranet&"

# Générer la requête
certreq -new request.inf request.csr

# Soumettre à la CA
certreq -submit -config "ca-emettrice.ayinedjimi.fr\AyiNedjimi Issuing CA 01" request.csr cert.cer

# Installer le certificat
certreq -accept cert.cer

Pour IIS, après installation du certificat dans le magasin Local Machine, assignez-le au site via le gestionnaire IIS : Site Bindings → Add → HTTPS → sélectionnez le certificat. Pour Apache sur Linux, suivez la procédure décrite dans notre article sur l'émission de certificats AD CS pour Linux.

Révoquer un certificat et gérer la CRL

La révocation est une composante critique du cycle de vie PKI. Un certificat compromis, expiré ou appartenant à un employé qui quitte l'organisation doit être révoqué immédiatement.

Dans la console Certification Authority (certsrv.msc) :

1. Naviguez vers "Issued Certificates"
2. Retrouvez le certificat à révoquer (filtrez par CN ou numéro de série)
3. Clic droit → All Tasks → Revoke Certificate
4. Choisissez le motif (Key Compromise, CA Compromise, Cessation of Operation, etc.)
5. Confirmez

Publiez immédiatement une nouvelle CRL :

# Via PowerShell
$CertCA = Connect-CertificationAuthority "ca-emettrice.ayinedjimi.fr"
Publish-CRLDistributionPoint -CertificationAuthority $CertCA -Delta

# Via certutil
certutil -CRL

La CRL (Certificate Revocation List) est publiée selon le planning configuré (par défaut toutes les semaines). La Delta CRL contient uniquement les changements depuis la dernière CRL complète et peut être publiée plus fréquemment (toutes les heures) pour réduire le délai entre révocation et prise en compte.

Pour les environnements modernes, envisagez d'activer l'OCSP (Online Certificate Status Protocol) qui permet une vérification en temps réel de l'état d'un certificat :

Install-WindowsFeature ADCS-Online-Cert -IncludeManagementTools
Install-AdcsOnlineResponder

Configurez le répondeur OCSP dans la console Online Responder et ajoutez l'URL OCSP dans vos modèles de certificats (extension AIA).

Sécuriser l'infrastructure PKI (accès physique Root CA, sauvegarde clé privée)

La sécurité de votre PKI est aussi forte que son maillon le plus faible. Un plan de sécurisation rigoureux doit couvrir plusieurs dimensions.

Protection physique de la Root CA : Le serveur Root CA doit être stocké dans un espace physiquement sécurisé, idéalement un coffre ignifuge ou une salle forte avec contrôle d'accès biométrique. Seuls 2-3 administrateurs PKI nommés doivent y avoir accès. Documentez chaque accès dans un registre. Considérez l'utilisation d'un HSM (Hardware Security Module) pour protéger la clé privée même contre un accès physique non autorisé.

Sauvegarde de la clé privée :

# Sauvegarder la CA complète (base de données + clé privée)
certutil -backupDB C:\Backup\CA-DB
certutil -backupKey C:\Backup\CA-Key

# Chiffrer la sauvegarde
[Security.Cryptography.ProtectedData]::Protect(...)

# Stocker sur supports chiffrés (BitLocker)
# Conserver des copies dans 2 sites géographiques différents

Durcissement de la CA émettrice :

• Activez l'audit complet sur le serveur CA (voir notre article sur l'audit avancé Active Directory)
• Restreignez l'accès RDP aux seuls administrateurs PKI via une GPO dédiée
• Activez Windows Defender et désactivez les services inutiles
• Limitez les ports ouverts : 443 (Web Enrollment), 80 (CRL/AIA), 135/49152+ (RPC pour clients AD CS)
• Configurez des alertes sur les événements CA critiques (Event IDs 70, 71, 72 dans Application Log)

Procédure de renouvellement planifié : Planifiez le renouvellement de la CA émettrice 1 an avant son expiration. Pour la Root CA, déclenchez l'alerte 5 ans avant. Ces opérations doivent être documentées et répétées en environnement de test avant la production.

Pour une revue de sécurité complète de votre Active Directory, y compris votre PKI AD CS, nos experts proposent un pentest Active Directory incluant l'évaluation des configurations PKI contre les attaques ESC1 à ESC8 (ESCAlation vulnérabilités AD CS documentées par SpecterOps). Ces vulnérabilités peuvent permettre à un attaquant interne de s'élever jusqu'au niveau Domain Admin en quelques minutes, en exploitant des modèles de certificats mal configurés ou des permissions excessives sur l'interface d'enrollment.

Il est également recommandé de configurer des alertes SIEM sur les événements critiques de la CA : tentatives d'enrollment non autorisées, émissions massives de certificats, modifications de modèles ou de permissions. Les Event IDs 4886 (Certificate Request Received), 4887 (Certificate Issued) et 4888 (Certificate Denied) dans le journal Security de la CA sont particulièrement utiles pour détecter des comportements anormaux. Un tableau de bord dédié à la PKI dans votre solution SIEM permet de surveiller en continu la santé et la sécurité de votre infrastructure de confiance.

Enfin, documentez exhaustivement votre PKI : schéma d'architecture, procédures d'urgence (que faire si la CA émettrice tombe en panne ?), contacts des administrateurs PKI, emplacement des sauvegardes. Cette documentation doit être stockée hors ligne et mise à jour à chaque modification significative de l'infrastructure.

Référez-vous également à la documentation officielle Microsoft AD CS et aux recommandations du guide ANSSI sur la sécurisation des PKI pour compléter votre politique de sécurité.

FAQ — AD CS et PKI d'entreprise

Quelle est la différence entre une Root CA Standalone et une Enterprise Root CA ?

Une Root CA Standalone n'est pas intégrée à Active Directory et gère ses propres politiques de manière autonome. Elle est idéale pour la Root CA offline car elle n'a pas besoin de communiquer avec l'AD. Une Enterprise CA est intégrée à l'AD, utilise les groupes AD pour les permissions, et publie ses informations dans l'annuaire. La Subordinate/Issuing CA doit toujours être une Enterprise CA pour bénéficier des fonctionnalités d'auto-enrollment et des modèles de certificats intégrés.

Combien de temps faut-il prévoir pour déployer une PKI AD CS complète en production ?

Pour un déploiement en production soigné, comptez 3 à 5 jours de travail. La phase de conception et documentation préalable représente 1 jour. L'installation et la configuration des deux CA prennent 1 à 2 jours. La création et le test des modèles de certificats nécessitent 1 jour. Le déploiement en production et la validation finale (auto-enrollment sur tous les postes, vérification des CRL) occupent 1 à 2 jours supplémentaires. Un déploiement bâclé en quelques heures expose à des problèmes de configuration difficiles à corriger après la mise en production.

Peut-on migrer d'une PKI basée sur des certificats auto-signés vers une PKI AD CS sans interruption ?

Oui, mais la transition doit être planifiée soigneusement. La PKI AD CS est d'abord déployée en parallèle. Le certificat Root est distribué via GPO à tous les postes avant d'émettre de nouveaux certificats. Les anciens certificats auto-signés restent valides jusqu'à leur expiration naturelle ou sont remplacés progressivement. Une fenêtre de coexistence de 1 à 3 mois est recommandée pour gérer les serveurs moins fréquemment mis à jour. L'impact sur les utilisateurs est nul si la transition est bien orchestrée.

Les attaques ESC1 à ESC8 sur AD CS sont-elles réellement exploitables en production ?

Absolument. Les vulnérabilités ESC (ESCAlation) documentées par SpecterOps en 2021 sont activement exploitées dans des attaques réelles. ESC1 (modèle permettant à tout utilisateur de spécifier un SAN arbitraire) est particulièrement répandu dans les configurations par défaut héritées. ESC8 (relai NTLM vers l'interface Web Enrollment) est exploitable sans aucun privilège préalable. Un audit régulier avec Certify (outil open source) ou PSPKIAudit permet de détecter ces configurations dangereuses avant qu'un attaquant ne les exploite.

Faut-il un HSM pour sécuriser la clé privée de la Root CA ?

Un HSM (Hardware Security Module) est fortement recommandé pour toute PKI en production, surtout pour la Root CA. Il garantit que la clé privée ne quitte jamais le hardware sécurisé, est résistant aux attaques physiques et logiques, et simplifie les audits de conformité (PCI-DSS, ISO 27001). Des HSM certifiés FIPS 140-2 Level 3 sont disponibles à partir de quelques milliers d'euros (Thales Luna, Entrust nShield, YubiHSM pour des petits environnements). Sans HSM, la sauvegarde chiffrée de la clé sur un support physique sécurisé offline reste acceptable pour des PKI de taille modeste.