Interruption de service AD CS liée à l’expiration de la CRL d’une autorité racine hors ligne

Question

Interruption de service AD CS liée à l’expiration de la CRL d’une autorité racine hors ligne

Morel Élodie 80

Nous disposons d’une infrastructure PKI AD CS à deux niveaux, composée d’une Root CA hors ligne et d’une Issuing CA utilisée pour délivrer les certificats aux utilisateurs et aux serveurs de l’entreprise.

La CRL publiée par la Root CA a expiré avant qu’une nouvelle CRL puisse être générée et publiée. Depuis son expiration, l’Issuing CA rencontre des problèmes de validation de chaîne et les certificats associés commencent à être considérés comme non fiables dans l’environnement.

La Root CA étant volontairement maintenue hors ligne, nous devons effectuer cette opération manuellement, puis publier la nouvelle CRL sur les points de distribution appropriés.

Quelle est la procédure recommandée et supportée pour générer manuellement une nouvelle CRL sur la Root CA hors ligne, la signer correctement, puis la publier afin de rétablir la validation de la chaîne de certification ? Quels éléments devons-nous vérifier sur l’Issuing CA et sur les points de distribution après la publication de la nouvelle CRL ?

0 commentaires

1 réponse

Votre réponse

Answer 1

Bonjour Élodie,

Dans votre cas, la procédure supportée par Microsoft pour une Root CA hors ligne est la suivante : vous devez connecter temporairement la Root CA, générer une nouvelle CRL, la signer, puis la transférer manuellement vers les points de distribution configurés. Concrètement, ouvrez la console de certification (certsrv.msc) sur la Root CA, développez Revoked Certificates, faites un clic droit sur Revoked Certificates puis sélectionnez All Tasks > Publish. Choisissez de publier une nouvelle CRL. Cela va générer un fichier CRL signé par la Root CA, généralement situé dans %systemroot%\system32\certsrv\certenroll.

Ensuite, copiez ce fichier CRL vers les emplacements de distribution définis dans les extensions de la Root CA (LDAP, HTTP, ou UNC selon votre configuration). Si vous utilisez un partage de fichiers ou un site web pour la distribution, vous devez remplacer l’ancien fichier CRL par le nouveau, en respectant le même nom de fichier afin que les clients puissent le récupérer sans modification de chemin.

Sur l’Issuing CA, vérifiez que la nouvelle CRL est bien accessible. Vous pouvez utiliser certutil -urlfetch -verify <certificat.cer> pour tester la chaîne et confirmer que la CRL de la Root est correctement téléchargée et interprétée. Assurez-vous également que la date de validité de la nouvelle CRL est cohérente avec vos politiques (par exemple, une durée de validité suffisamment longue pour éviter une nouvelle expiration prématurée).

Enfin, contrôlez les points de distribution configurés dans les propriétés de la Root CA (onglet Extensions dans la console Certification Authority). Vérifiez que les chemins LDAP ou HTTP sont toujours valides et que le fichier CRL est bien présent et accessible. Sur l’Issuing CA, vous pouvez aussi lancer certutil -crl pour forcer une mise à jour locale et confirmer que la nouvelle CRL est prise en compte.

En résumé, la séquence est : génération manuelle de la CRL sur la Root CA hors ligne, copie vers les points de distribution, vérification de l’accessibilité et de la validité depuis l’Issuing CA et les clients. C’est la méthode officielle et supportée pour maintenir une PKI à deux niveaux avec une Root hors ligne.

J’espère que vous avez trouvé des éléments utiles ici. Si cela vous aide à mieux comprendre le problème, merci d’accepter la réponse. Si vous avez d’autres questions, n’hésitez pas à laisser un message. Bonne journée !HP.