Migrer AD CS Windows Server 2012 R2 vers 2019/2022/2025 : guide complet pas à pas

Besoin de faire évoluer votre PKI sans stress ? Voici un guide opérationnel pour migrer une autorité de certification AD CS depuis Windows Server 2012 R2 vers 2019/2022/2025, en conservant la configuration, la continuité de service et la validité des chaînes.

Sommaire

Vue d’ensemble

Objectif : déplacer une autorité de certification (AC) Active Directory Certificate Services d’un serveur Windows Server 2012 R2 vers une version plus récente (2019, 2022 ou 2025), sans régénérer l’AC, sans perdre la base, et sans casser la validation de révocation sur les postes et serveurs existants. La méthode la plus fiable est une migration side‑by‑side vers une nouvelle machine.

Réponse et solution

Méthode recommandée : migration side‑by‑side (pas de mise à niveau sur place). On prépare un nouveau serveur, on y réinstalle AD CS en réutilisant le même nom d’AC et la même clé privée, on restaure la base, on ajuste la publication CRL/AIA, on valide, puis on bascule. Cette approche offre un excellent retour arrière, isole les risques et permet des tests avant la mise en production.

Principes clés à respecter

Le nom de l’AC doit rester identique (ex. Contoso‑Enterprise‑CA) pour préserver l’identité PKI et la continuité des chaînes existantes.
Le nom d’hôte du serveur peut être différent. C’est même souvent préférable pour éviter les collisions de noms et les quotas DNS.
Les CDP (CRL Distribution Points) et AIA inscrits dans les certificats émis peuvent contenir l’ancien FQDN. Il faut continuer à publier aux anciens chemins/URL (ou maintenir des alias) pour ne pas casser la vérification de révocation.
Sur le nouveau serveur : réutilisez le certificat d’AC et sa clé privée (PFX protégé) au lieu d’en créer un nouveau.
Pensez aux dépendances : IIS/HTTP pour CRL/AIA, partages de fichiers, HSM (pilotes, middleware, slots), pare‑feu/DCOM, comptes et droits NTFS.

Ce qui doit rester identique vs ce qui peut changer

Élément	Doit rester identique	Peut changer	Remarques
Nom de l’AC (Common Name)	Oui	Non	Base de confiance des chaînes existantes.
Nom du serveur (FQDN)	Non	Oui	Autorisé et recommandé. Maintenir URL CRL/AIA valides.
Clé privée de l’AC	Oui	Non (sauf réémission planifiée)	Réutiliser la clé; la changer impose une re‑publication étendue.
Base AD CS (certificats émis, demandes)	Oui	—	Restauration obligatoire.
CDP/AIA effectifs	Oui (continuité)	Évolution possible	Ajouter de nouveaux chemins tout en gardant les anciens.
Modèles de certificats (AD)	—	—	Stockés dans AD : pas impactés par la migration de l’AC.

Architecture, prérequis et préparation

Le nouveau serveur doit être joint au même domaine AD et disposer des mises à jour de sécurité.
Prévoir un alias DNS stable pour la publication (ex. pki.contoso.com) pointant vers le serveur actif.
Si publication HTTP : installer IIS et les mêmes répertoires virtuels (CertEnroll typiquement).
Si HSM : installer pilotes/middleware, initialiser le slot, valider l’accès avant restauration.
Fenêtre de maintenance : geler temporairement l’émission de certificats le temps de la bascule.

Élément à sauvegarder	Où le trouver	Commande / action	Pourquoi
Base AD CS	`%SystemRoot%\System32\CertLog`	`certutil -backupdb C:\CA-Backup\db`	Historique des émissions, files d’attente.
Clé privée + certif. AC	Magasin machine	`certutil -backupKey C:\CA-Backup\key`	Identité de l’AC, à réimporter.
Configuration registre	HKLM\SYSTEM\…\CertSvc\Configuration	`reg export ... C:\CA-Backup\CA.reg`	CDP/AIA, périodes CRL, chemins, etc.
Répertoire de publication	`%SystemRoot%\System32\CertSrv\CertEnroll`	Copie/archivage	CRL/AIA existants et IIS.
CAPolicy.inf (si présent)	`C:\Windows\CAPolicy.inf`	Copie/archivage	Directives de l’AC, publication CRL par défaut.

Procédure pas à pas

Préparation sur l’ancien serveur

Geler l’émission et arrêter le service AD CS : net stop certsvc
Inventorier la configuration (utile pour comparer après restauration) : mkdir C:\CA-Backup certutil -getreg CA > C:\CA-Backup\ca-reg.txt certutil -getreg CA\CRLPublicationURLs >> C:\CA-Backup\ca-reg.txt certutil -getreg CA\CACertPublicationURLs >> C:\CA-Backup\ca-reg.txt certutil -store my >> C:\CA-Backup\store-my.txt certutil -store ca >> C:\CA-Backup\store-ca.txt
Sauvegarder base, clé privée et certificat : certutil -backupdb C:\CA-Backup\db certutil -backupKey C:\CA-Backup\key Protégez le PFX par un mot de passe fort, stocké de façon sécurisée.
Exporter la configuration registre : reg export "HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration" C:\CA-Backup\CA.reg
Archiver la publication (HTTP/partage) et la config IIS le cas échéant : xcopy "%SystemRoot%\System32\CertSrv\CertEnroll" C:\CA-Backup\CertEnroll /E /I /H /K

Installation du nouveau serveur

Joindre le domaine, appliquer les mises à jour, installer pilotes HSM si nécessaires.
Installer les rôles requis : Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools # Publication HTTP si utilisée Install-WindowsFeature Web-Server, Web-Static-Content
Importer le PFX (clé + certificat de l’AC) dans le magasin machine : $pwd = Read-Host "Mot de passe PFX" -AsSecureString Import-PfxCertificate -FilePath "C:\CA-Backup\key\<VotrePFX>.p12" -Password $pwd -CertStoreLocation Cert:\LocalMachine\My | Out-Null
Configurer AD CS en réutilisant le certificat existant : Exécutez l’assistant « Configurer les services de certificats Active Directory » et choisissez « Utiliser un certificat existant et sa clé privée ». Vérifiez que le nom de l’AC correspond exactement à l’ancien. Laissez la base aux emplacements par défaut (ou choisissez un volume dédié).
Arrêter le service puis restaurer la base et la configuration : net stop certsvc certutil -restoredb C:\CA-Backup\db reg import C:\CA-Backup\CA.reg Copiez au besoin le contenu du répertoire CertEnroll et reconfigurez IIS (site, répertoire virtuel, droits NTFS).
Adapter/valider les CDP et AIA pour inclure anciens et nouveaux chemins (voir section dédiée). Idéalement, utilisez un alias DNS comme pki.contoso.com qui pointera vers le serveur actif.
Démarrer le service et publier une CRL immédiatement : net start certsvc certutil -crl

Validation et bascule

Contrôler que l’objet pKIEnrollmentService d’AD pointe vers le nouveau FQDN (mise à jour automatique au démarrage du service).
Tester l’inscription d’un certificat (via MMC ou Autoenrollment), la construction de chaîne et le téléchargement CRL/AIA depuis un poste client.
Surveiller les journaux (Application et ADCS Certification Authority), vérifier l’absence d’erreurs de publication.
Après quelques jours de validation, désinstaller le rôle sur l’ancien serveur et archiver ses sauvegardes. Ne supprimez l’ancienne VM/clé qu’une fois la stabilité confirmée.

Gestion fine des CDP et AIA

Les CDP et AIA présents dans les certificats déjà émis doivent rester valides jusqu’à expiration. Cela implique :

De continuer à publier la CRL et la Delta CRL aux anciens emplacements (HTTP/LDAP/chemins de fichiers) ou de mettre en place des alias/redirections qui conservent les URL historiques.
De rajouter vos nouveaux chemins (par ex. un alias générique http://pki.contoso.com/CertEnroll/) pour les certificats futurs.

Exemples d’actions usuelles :

Créer un alias DNS pki.contoso.com vers le nouveau serveur.
Dans la console Autorité de certification → Propriétés → Extensions, vérifier/ajouter les entrées CDP/AIA nécessaires (HTTP et LDAP), avec les bons indicateurs (inclure dans les CRL, inclure dans les certificats émis, publier en tant que…).
Vérifier les droits NTFS/partage et le compte ordinateur du nouveau serveur sur les répertoires de publication.
Publier une CRL et une Delta CRL immédiatement après modification.

Type	Exemple de chemin/URL	But	Bonnes pratiques
CDP HTTP	`http://pki.contoso.com/CertEnroll/%3%8%9.crl`	Point principal pour clients Windows et non‑Windows.	Alias DNS stable. Publier CRL et Delta CRL.
AIA HTTP	`http://pki.contoso.com/CertEnroll/%1_%3%4.crt`	Distribution du certificat de l’AC.	Conserver l’ancien FQDN tant que des certifs y pointent.
CDP LDAP	`ldap:///CN=%7,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=...`	Robuste en environnement AD.	Laisser activé pour redondance.

Cas d’un serveur portant un nouveau nom

C’est non seulement autorisé, mais recommandé. Seules exigences :

Nom de l’AC identique à l’ancien (obligatoire).
URL CDP/AIA historiques maintenues (publication double, alias DNS, redirection HTTP).
Standardisez pour l’avenir : utilisez des URL neutres (alias) afin de découpler la publication du nom du serveur.

Spécificités HSM et fournisseurs cryptographiques

Réinstallez le middleware HSM, importez le jeton/slot, vérifiez l’accès de Local System (ou du compte de service si différent).
CSP vs KSP : la migration n’échange pas le fournisseur. Si votre clé d’AC est en CSP, vous continuerez en CSP tant que vous réutilisez cette clé. Le passage en KSP implique une réémission de l’AC (changement de clé) et un projet séparé.
Assurez la compatibilité algorithme/hash (SHA‑256 recommandé), et vérifiez la taille de clé (2048/3072/4096) selon vos politiques.

Rôles associés et impacts

Web Enrollment : si utilisé, réinstallez et sécurisez IIS. Vérifiez l’accès authentifié.
NDES (SCEP) : migration séparée. Notez les secrets, les certificats d’échange de clés, et les URIs SCEP.
OCSP : mettez à jour la Responder Signing, repointez les autorités dans la config OCSP, conservez les URL historiques si présentes dans les AIA.

Validation détaillée après migration

Publication : certutil -crl certutil -urlfetch -verify <CheminVersUnCertificatÉmis>
Résolution d’objet AD (pKIEnrollmentService) et Enrollment client : # Exemple de vérification avec RSAT AD Get-ADObject -LDAPFilter "(cn=*<NomDeVotreAC>*)" -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com" -Properties dNSHostName | ft cn,dNSHostName
Chaînes et révocation depuis un poste standard : ouvrir un certificat puis Chemin d’accès de certification → vérifier la CRL et les AIA.
Journaux et files d’attente dans la console AD CS : absence d’erreurs de publication et d’inscription.

Plan de retour arrière

Laisser l’ancien serveur arrêté mais intact quelques jours.
En cas d’anomalie majeure : arrêter le nouveau service, réactiver l’ancien (publication CRL prioritaire), corriger, puis retenter la bascule.
Ne jamais avoir deux services actifs portant le même nom d’AC simultanément.

FAQ minute

Faut‑il garder le même nom d’hôte ? Non. Le serveur peut changer de nom. C’est le nom de l’AC qui doit rester identique.

Dois‑je regénérer l’AC ? Non. Réutilisez le certificat et la clé privée existants (PFX).

Que deviennent les modèles de certificats ? Ils sont stockés dans AD. La migration de l’AC ne les supprime pas.

Et si mes CDP/AIA pointent sur l’ancien FQDN ? Maintenez la publication sur ces chemins (ou des alias/redirects) jusqu’à expiration des certificats concernés.

Puis‑je profiter pour passer en SHA‑256/KSP ? Si votre AC est déjà en SHA‑256, vous êtes bon. Le passage de CSP vers KSP implique un changement de clé et donc un projet de réémission de l’AC.

Sécurisation post‑migration

Activer l’audit AD CS et les journaux d’accès IIS.
Limiter l’accès au répertoire de publication (NTFS) au strict nécessaire.
Définir une période de chevauchement CRL (CRL overlap) pour prévenir toute fenêtre sans CRL valide.
Documenter les nouveaux chemins CDP/AIA et l’alias DNS standard.
Planifier une révision annuelle des paramètres et des dates d’expiration.

Exemples de commandes utiles

# Forcer la publication CRL/DeltaCRL
certutil -crl

# Vérifier la configuration enregistrée

certutil -getreg CA
certutil -getreg CA\CRLPublicationURLs
certutil -getreg CA\CACertPublicationURLs

# Vérifier le magasin et le fournisseur cryptographique

certutil -store my

# Tester la chaîne et le téléchargement CRL/AIA

certutil -url \

Procédure condensée (check‑list)

Sauvegarder sur l’ancien serveur : base, PFX (clé+certificat), registre, publication IIS/partage, CAPolicy.inf si présent.
Installer un nouveau Windows Server 2019/2022/2025, joindre le domaine, installer AD CS, IIS si nécessaire, pilotes HSM.
Réutiliser la même identité d’AC (nom, certificat, clé). Restaurer la base et la configuration.
Adapter CDP/AIA pour conserver les anciens chemins tout en introduisant les nouveaux (alias DNS recommandé).
Publier une CRL, tester l’inscription et la validation de chaînes, surveiller les journaux.
Retirer proprement l’ancien serveur une fois la stabilité confirmée et archiver les sauvegardes.

Annexe : points d’attention terrain

Pare‑feu : AD CS utilise RPC/DCOM (port 135 + ports dynamiques). S’assurer que les règles sont en place, surtout si la console à distance est utilisée.
Droits d’écriture sur les emplacements de publication (HTTP/partages). Le compte ordinateur du nouveau serveur doit pouvoir écrire.
Heure et NTP : la cohérence temporelle influence la validation des CRL et la création de signatures.
Nettoyage des anciennes CRL/AIA orphelines après bascule, en gardant ce qui est encore référencé par des certificats non expirés.
Surveillance : mettez en place des alertes pour l’expiration CRL et le remplissage du journal de base de données.

Conclusion

La migration d’une AC AD CS de Windows Server 2012 R2 vers 2019/2022/2025 est fiable et prévisible lorsqu’elle est menée en side‑by‑side : on conserve l’identité de l’AC, on restaure la base et la configuration, on maintient les CDP/AIA historiques, on teste puis on bascule. En suivant le pas à pas et les bonnes pratiques ci‑dessus, vous préservez la confiance de votre PKI et offrez une trajectoire de modernisation sereine.

Rappel essentiel : le nom de l’AC reste le même, le serveur peut changer. Publiez vos CRL/AIA aux emplacements historiques, ajoutez un alias DNS stable, et validez avant démantèlement de l’ancien hôte.