MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Migration CA Windows : corriger AIA et CDP après changement de serveur

Migration CA Windows : corriger AIA et CDP après changement de serveur

Windows Server

La migration d’une autorité de certification Windows n’est pas qu’un simple déplacement de rôle : le moindre oubli sur les URL AIA et CDP peut paralyser toute votre infrastructure PKI. Ce guide exhaustif vous accompagne pas à pas pour corriger les chemins après changement de serveur et rétablir un environnement sain et sécurisé.

Sommaire

Vue d’ensemble du problème

Lorsque la CA est déplacée sur un nouveau serveur dont le nom diffère, les extensions Authority Information Access (AIA) et CRL Distribution Points (CDP) embarquées dans les certificats restent figées sur l’ancien FQDN. Immédiatement :

  • pkiview.msc remonte des croix rouges ; les indicateurs « Fetch » et « Revocation » échouent.
  • Les postes clients ne peuvent plus télécharger la CRL, d’où des échecs d’authentification TLS, IPsec et Smart Card.
  • Un certificat racine « CA(1) » peut apparaître si un renouvellement mal préparé a été tenté.

Pourquoi les URL AIA/CDP sont‑elles critiques ?

Chaque certificat émis contient une liste d’emplacements où :

  • Les clients récupèrent la chaîne de confiance (AIA).
  • Les terminaux vérifient le statut de révocation (CDP).

Si ces URL sont erronées, tous les certificats déjà déployés deviennent inutilisables, même si leur date de fin de validité n’est pas échue : la confiance ne peut plus être validée.

Prérequis avant toute correction

  • Être membre du groupe Enterprise Admins ou disposer d’une délégation équivalente.
  • Disposer d’un accès console à la nouvelle CA et à Active Directory.
  • Avoir sauvegardé la clé privée et la configuration (certutil –backupdb & –backupkey).
  • S’assurer que le nouveau serveur est à jour (KB, correctifs de sécurité) ; la moindre instabilité réseau peut fausser les tests PKI.

Étapes détaillées de résolution

1. Corriger les extensions AIA et CDP

Dans certsrv.msc :

  1. Ouvrez les Propriétés du CA, onglet Extensions.
  2. Pour chaque type (CDP puis AIA), supprimez les entrées qui pointent vers l’ancien nom.
  3. Ajoutez les nouveaux chemins (http://nouveauCA.contoso.com/CertEnroll/%%3%%8%%9.crl, ldap:///CN=...%%6%%20%%7%%8…).
  4. Cochez :
    – Publier dans Active Directory si vous utilisez LDAP.
    – Inclure dans les extensions des certificats émis pour rendre les URL visibles des clients.
  5. Appliquez puis redémarrez le service Active Directory Certificate Services.

2. Nettoyer Active Directory

L’AD conserve d’anciennes références dans le conteneur CN=Public Key Services. À l’aide d’ADSI Edit :

  1. Parcourez Configuration → Services → Public Key Services.
  2. Supprimez les objets AIA et CDP obsolètes (leurs attributs cACertificate et certificateRevocationList pointent vers l’ancien FQDN).
  3. Vérifiez que le conteneur Certification Authorities ne contient pas de certificat racine dépassé.

3. Renouveler le certificat de la CA

La méthode la plus propre consiste à forcer un renouvellement :

certsrv.msc → clic droit sur la CA → All Tasks → Renew CA Certificate

Avec la même clé : vous conservez la continuité de la hiérarchie.
Avec une nouvelle clé : à envisager si l’ancien couple clé/certificat est compromis ou insuffisant (SHA‑1, 1024 bits, etc.).

Le renouvellement génère :

  • Un nouveau certificat de CA contenant les URL corrigées.
  • Une publication immédiate de la CRL et de la delta CRL dans les nouveaux emplacements.
  • La mise à jour automatique des attributs LDAP et des entrées de registre.

4. Republier les listes de révocation

Même si la CA le fait normalement elle‑même, forcez l’action pour éviter tout cache DNS ou proxy :

certutil –crl
certutil –setreg CA\CRLPublicationInterval Hours 1  rem : optionnel
net stop certsvc && net start certsvc       rem : ou redémarrage complet du serveur

5. Vérifications post‑migration

ActionCommande / OutilRésultat attendu
Contrôle PKIViewpkiview.mscAucune erreur rouge ; toutes les URL accessibles.
Test chaîne et révocationcertutil –verify –urlfetch user.cer« Certificate is valid » et accès CRL OK.
Audit évènementsObservateur d’évènements → CertificationAuthorityAbsence d’Event ID 48xx/53xx.

Automatisation & industrialisation

Dans un grand environnement, le cliquer‑glisser n’est pas une option. Automatisez via certutil :

certutil –getreg CA\CRLPublicationURLs
certutil –setreg CA\CRLPublicationURLs "2:http://pki.contoso.com/CertEnroll/%3%8%9.crl"
certutil –setreg CA\CACertPublicationURLs   "1:http://pki.contoso.com/CertEnroll/%1_%3%4.crt"

Puis :

sc query certsvc | find "RUNNING" && net stop certsvc && net start certsvc
gpupdate /force  rem : si GPO distribue le certificat racine

Bonnes pratiques pour éviter la panne

  • DNS CNAME ou alias A : conservez l’ancien FQDN ou créez un CNAME pointant vers le nouveau serveur tant que des certificats obsolètes circulent.
  • Durée de vie raisonnable des certificats de CA : 10 ans maximum, afin de pouvoir renouveler plus fréquemment et mettre à jour les URL.
  • Plan de distribution : utilisez des GPO ou un MDM pour pousser automatiquement le certificat racine re‑signé.
  • Monitoring : intégrez l’Event ID 48xx dans vos alertes SIEM ; tout échec de publication CRL doit déclencher un ticket.

FAQ

Que se passe‑t‑il si je laisse l’ancien nom indisponible ?

Les certificats déjà émis continueront de pointer vers une URL morte ; les validations OCSP/CRL échouent, provoquant des refus TLS ou RDP selon la stratégie d’applications.

Puis‑je éditer un certificat déjà émis pour changer les URL ?

Non. Les champs AIA/CDP sont signés ; toute modification invaliderait la signature. Il faut ré‑émettre les certificats quand c’est indispensable.

Mon environnement supporte OCSP ; dois‑je quand même corriger la CRL ?

Oui. De nombreux composants Windows utilisent la CRL comme solution de repli quand l’OCSP ne répond pas ou n’est pas configuré.

Erreurs fréquentes et correctifs rapides

SymptômeCause probableCorrectif
Event ID 48, « Failed to retrieve CRL … »URL CDP injoignable ou syntaxe incorrecte.Vérifier DNS, pare‑feu, proxy. certutil –ping permet de tester.
Certificats refusés « The revocation function was unable to check … »Delta CRL manquante (.crl+).certutil –setreg CA\CRLFlags +CRLF_DELTA_ENABLE puis –crl.
« CA(1) » dans Trusted RootRenouvellement avec nouvelle clé sans supprimer l’ancienne entrée.Nettoyer GPO « Trusted Root Certification Authorities » puis redistribuer.

Conclusion

La clé d’une migration réussie de votre autorité de certification réside dans l’anticipation des dépendances AIA/CDP. En mettant à jour les chemins, en renouvelant proprement le certificat de CA et en validant chaque étape à l’aide d’outils natifs (pkiview.msc, certutil), vous assurez la continuité des services PKI sans perte de confiance ni interruption applicative.

En suivant ce guide, vous évitez les écueils classiques, rétablissez le téléchargement de la CRL et garantissez à vos utilisateurs une expérience transparente, même après un changement majeur d’infrastructure.

Windows Server
Sommaire