Pulling an ADCS CA out of service looks like a five-minute job. Uninstall the role, delete the VM, done. That version of the work creates problems that surface weeks later, usually as certificate validation failures nobody connects back to the CA you retired.
The role uninstall is trivial. The lifecycle around it is not. A CA that stops running does not stop mattering. Every certificate it ever issued keeps pointing back at it for revocation checking until that certificate expires, and the CA's footprint in Active Directory keeps advertising it to clients until you remove each object by hand. Decommissioning done properly is mostly about winding those two things down, in the right order.
This is the hub for the decommissioning topic. The detail on revocation mechanics, backups, migration, and renewal lives in the linked articles. What follows is the shape of the whole job and the sequence it has to happen in.
The examples below use a demo environment: two forests, pixa.ca and ranidae.net, joined by a two-way transitive forest trust, with a separate unrelated organisation, qcraft.ca, for contrast. The CA coming out of service is pixa-ICA-01, an enterprise issuing CA in pixa.ca, with issuance moving to pixa-ICA-02.
First decision: decommission, migrate, or retire in place
Three different outcomes get filed under "decommissioning," and they are not the same job.
Migrate if you still need this CA to issue certificates and you are only moving it to new hardware or a new OS. That is a different procedure built around preserving the key and database. See Migrating a CA to new hardware or OS. Do not decommission a CA you actually intend to keep.
Retire in place if you need issuance to stop now but revocation to continue. The CA stops handing out new certificates, but it keeps signing CRLs, or you publish one long CRL, so the certificates already in the field stay verifiable.
Decommission if issuance must stop and, eventually, revocation too, once every certificate this CA issued has expired or been reissued from somewhere else.
Most "decommission this CA" tickets are really retire-in-place now, followed by a true decommission months later when the last issued certificate finally expires. Plan for both phases up front, not just the part that fits in this week's change window.
Inventory before you touch anything
You cannot safely remove revocation infrastructure while valid certificates still depend on it. So the first real task is finding out what pixa-ICA-01 issued and what points at it.
Pull the list of unexpired certificates from the CA database. Run certutil -view against pixa-ICA-01, or query the database directly, and filter for certificates whose NotAfter is still in the future. That set defines your timeline. The CA's revocation infrastructure has to stay reachable until the last of those expires, or until you reissue them from pixa-ICA-02.
[SCREENSHOT] certutil -view output (or the Issued Certificates view in certsrv.msc) on pixa-ICA-01, filtered to unexpired certificates, showing the Certificate Expiration Date column
Then find the dependents:
- Templates published only on pixa-ICA-01. Anything enrolling against them needs pixa-ICA-02 to publish the same template first.
- Autoenrollment and enrollment policy pointing at pixa-ICA-01.
- Applications and services holding certificates from this issuer: TLS endpoints, NDES, code signing, anything pinned to the issuer name or key.
- OCSP responders configured with a revocation provider for this CA.
- Cross-forest publication. If you pushed pixa-ICA-01's certificate, AIA, or CRL into ranidae.net over the trust, those copies exist independently and have to be cleaned separately. qcraft.ca has no trust to pixa.ca, so it holds no copies and needs nothing. See Cross-forest PKI.
The CDP and AIA URLs baked into already-issued certificates are the part that bites. Those URLs are fixed at issuance and cannot be changed retroactively. They have to keep resolving and serving valid data until every certificate carrying them has expired.
The revocation continuity problem
This is the core of the whole exercise, and the reason the naive uninstall fails.
Every certificate pixa-ICA-01 issued carries CDP URLs telling relying parties where to fetch the CRL. When a client validates one of those certificates, it fetches the CRL to check whether the certificate has been revoked. Take the CA offline and let those URLs go dark, and you have broken revocation checking for every still-valid certificate it issued.
What happens next depends entirely on the relying party. Some clients soft-fail and treat an unreachable CRL as "not revoked." Plenty of others hard-fail. Do not assume soft-fail. Smartcard logon, many TLS stacks, code-signing validation, and anything tuned for security tend to treat a missing CRL as a failure. The failure is also delayed and confusing, because it only appears once the currently cached CRL expires, which can be days or weeks after you decommissioned anything.
You have three ways to handle it:
1. Keep signing CRLs until the last issued certificate expires. Lowest risk, but it means keeping the CA, or at least its key and CRL-signing function, alive for the full window.
2. Publish one long-dated CRL before you take the CA offline. Extend the CRL validity to span past the expiry of the last issued certificate, publish it, and serve it from a location that outlives the CA host. The cost is that you can no longer revoke anything for the life of that CRL. For a CA you are killing, that is usually acceptable, but make the call deliberately, not by accident.
3. Decouple the CDP from the CA host. Move CRL serving to a web or file location that keeps answering after the CA box is gone, and make sure the final CRL lives there. This is the cleanest outcome when the issued certificates have a long tail.
[SCREENSHOT] Certification Authority console (certsrv.msc) on pixa-ICA-01 showing the published CRL properties with an extended Next Update date
The registry settings for CRL validity and overlap, and the CDP placement details, are their own topic. See CRL, CDP and AIA management.
Stop issuance cleanly
Once revocation continuity is decided, stop pixa-ICA-01 taking new work.
Unpublish the templates from the CA so it stops accepting requests for them. Redirect autoenrollment and any enrollment policy to pixa-ICA-02. If you are retiring in place, you can stop accepting requests while still publishing CRLs. If you are going straight to decommission, publish your final CRL first, then stop the service.
Back up the CA database and private key before anything destructive, and keep that backup through your retention and audit window. You may need it to prove revocation status later, and in rare cases to stand the CA back up purely to revoke something. See Backing up and restoring a CA.
Remove the Active Directory footprint
An Enterprise CA publishes itself into several containers under the Configuration partition. Uninstalling the role removes some of these, but it reliably leaves orphans, so treat removal as a manual, verified step. Order matters, because some objects have to outlive others.
- Enrollment Services (
CN=Enrollment Services). Removing pixa-ICA-01's entry here stops clients discovering it for enrollment. Safe once issuance has moved to pixa-ICA-02.
- CDP container (
CN=CDP). If issued certificates reference an LDAP CDP, the CRL object here must stay until those certificates expire. Do not remove it early.
- AIA container (
CN=AIA). Holds the CA certificate for chain building. Same rule. Keep it while certificates that chain through pixa-ICA-01 are still in use.
- NTAuthCertificates (
CN=NTAuthCertificates). If this CA was trusted for certificate-based authentication, removing it here withdraws that trust domain-wide. Only remove once no authentication certificate from this CA is still in use, or you cause logon failures. View with certutil -viewstore -enterprise NTAuth and remove the specific entry, not the whole store.
- Certification Authorities (
CN=Certification Authorities). Root CA certificates distributed as trusted roots. Removing a root here distrusts it across the domain. This is the last thing you touch, and only for a root you are fully retiring once every certificate beneath it is gone.
[SCREENSHOT] ADSI Edit on the Configuration partition, CN=Public Key Services > CN=Enrollment Services, with pixa-ICA-01 listed
[SCREENSHOT] certutil -viewstore -enterprise NTAuth output listing the pixa CA certificates
certutil -dsdel pixa-ICA-01 is the supported way to remove a CA's objects from AD, but understand what it touches before you run it. In a multi-CA forest like pixa.ca, it can reach more than you intend. In practice many people remove objects deliberately and verify each one in pkiview.msc rather than firing a single blunt command.
If pixa-ICA-01 or the pixa root was published into ranidae.net over the two-way trust, the copies there are separate objects and survive everything you do in pixa.ca. Clean them in the ranidae.net forest as a distinct step.
[SCREENSHOT] The pixa CA certificate present in the ranidae.net forest (AIA or NTAuth container), reached over the two-way transitive trust
Order of operations
- Inventory issued certificates and dependents. Decide: decommission, migrate, or retire in place.
- Stop accepting new requests. Unpublish templates, redirect enrollment to pixa-ICA-02.
- Handle revocation continuity. Publish a final or long-dated CRL and confirm the CDP locations keep serving it.
- Wait out or reissue the still-valid certificates, depending on strategy.
- Back up the database and key. Keep the backup through the retention window.
- Remove the AD footprint: Enrollment Services first, then NTAuth, AIA, CDP, and Certification Authorities only once their dependents are gone.
- Uninstall the role and decommission the host.
- Clean up the trailing pieces: DNS records, OCSP configuration, NDES, monitoring, the ranidae.net cross-forest copies, backup jobs.
The ways this goes wrong
- Killing the host before publishing a CRL that outlasts the issued certificates. The failure is silent until the last cached CRL expires, then arrives as someone else's outage.
- Removing NTAuth or the root from Certification Authorities while authentication certificates from pixa-ICA-01 are still in use. Logon failures, usually blamed on everything except the retired CA.
- Forgetting cross-forest published copies. The CA is gone from pixa.ca but still advertised in ranidae.net. See Cross-forest PKI.
- Treating
certutil -dsdel as a one-step solution and removing shared objects in a multi-CA forest.
- Discarding the database backup too early and losing the ability to prove or change revocation status.
Verify
pkiview.msc (Enterprise PKI) is the fastest health check before and after. Confirm that clients no longer discover pixa-ICA-01 for enrollment, that CRLs still validate for the certificates still in the field, and that chain building behaves as intended: still working for outstanding certificates, or intentionally broken for a fully retired root.
[SCREENSHOT] pkiview.msc (Enterprise PKI) showing pixa.ca CA health before decommissioning, endpoints green
Retirer une AC ADCS du service a l'air d'une tâche de cinq minutes. On désinstalle le rôle, on supprime la machine virtuelle, c'est réglé. Cette version-là du travail crée des problèmes qui refont surface des semaines plus tard, en général sous forme d'échecs de validation de certificats que personne ne rattache à l'AC qu'on a retirée.
La désinstallation du rôle est triviale. Le cycle de vie autour ne l'est pas. Une AC qui cesse de fonctionner ne cesse pas d'avoir de l'importance. Chaque certificat qu'elle a émis continue de pointer vers elle pour la vérification de révocation jusqu'à l'expiration de ce certificat, et son empreinte dans Active Directory continue de l'annoncer aux clients tant qu'on n'a pas retiré chaque objet à la main. Une mise hors service bien faite consiste surtout à liquider ces deux éléments, dans le bon ordre.
Ceci est la page pivot du sujet. Le détail sur la mécanique de révocation, les sauvegardes, la migration et le renouvellement se trouve dans les articles liés. Ce qui suit, c'est la forme générale du travail et la séquence à respecter.
Les exemples utilisent un environnement de démonstration : deux forêts, pixa.ca et ranidae.net, reliées par une approbation de forêt bidirectionnelle transitive, plus une organisation distincte et sans lien, qcraft.ca, à titre de contraste. L'AC qu'on retire est pixa-ICA-01, une AC émettrice d'entreprise dans pixa.ca, et l'émission bascule vers pixa-ICA-02.
Première décision : mise hors service, migration ou retrait sur place
Trois résultats différents se retrouvent classés sous « mise hors service », et ce ne sont pas les mêmes travaux.
Migration si vous avez encore besoin que cette AC émette des certificats et que vous ne faites que la déplacer vers du nouveau matériel ou un nouveau système d'exploitation. C'est une autre procédure, bâtie autour de la conservation de la clé et de la base de données. Voir Migrer une AC vers du nouveau matériel ou un nouveau SE. Ne mettez pas hors service une AC que vous comptez réellement garder.
Retrait sur place si vous devez arrêter l'émission maintenant mais maintenir la révocation. L'AC cesse de distribuer de nouveaux certificats, mais elle continue de signer des LRC (CRL), ou vous publiez une LRC à longue échéance, pour que les certificats déjà en circulation restent vérifiables.
Mise hors service si l'émission doit cesser et, à terme, la révocation aussi, une fois que chaque certificat émis par cette AC aura expiré ou aura été réémis ailleurs.
La plupart des billets « mettre cette AC hors service » sont en réalité un retrait sur place maintenant, suivi d'une vraie mise hors service des mois plus tard, quand le dernier certificat émis finit par expirer. Planifiez les deux phases d'entrée de jeu, pas seulement la partie qui entre dans la fenêtre de changement de la semaine.
Inventaire avant de toucher à quoi que ce soit
Vous ne pouvez pas retirer en toute sécurité l'infrastructure de révocation tant que des certificats valides en dépendent. La première vraie tâche consiste donc à découvrir ce que pixa-ICA-01 a émis et ce qui pointe vers elle.
Sortez la liste des certificats non expirés depuis la base de données de l'AC. Exécutez certutil -view contre pixa-ICA-01, ou interrogez la base directement, et filtrez les certificats dont la date d'expiration (NotAfter) est encore dans le futur. Cet ensemble définit votre échéancier. L'infrastructure de révocation de l'AC doit rester joignable jusqu'à l'expiration du dernier de ces certificats, ou jusqu'à ce que vous les réémettiez depuis pixa-ICA-02.
[CAPTURE] Sortie de certutil -view (ou la vue Certificats émis dans certsrv.msc) sur pixa-ICA-01, filtrée sur les certificats non expirés, avec la colonne Date d'expiration du certificat
Ensuite, repérez les dépendances :
- Les modèles publiés uniquement sur pixa-ICA-01. Tout ce qui s'inscrit contre eux a besoin que pixa-ICA-02 publie d'abord le même modèle.
- L'inscription automatique et la stratégie d'inscription pointant vers pixa-ICA-01.
- Les applications et services détenant des certificats de cet émetteur : points d'extrémité TLS, NDES, signature de code, tout ce qui est épinglé au nom ou à la clé de l'émetteur.
- Les répondeurs OCSP configurés avec un fournisseur de révocation pour cette AC.
- La publication interforêts. Si vous avez poussé le certificat, l'AIA ou la LRC de pixa-ICA-01 vers ranidae.net via l'approbation, ces copies existent de façon indépendante et doivent être nettoyées séparément. qcraft.ca n'a aucune approbation vers pixa.ca, ne détient donc aucune copie et ne requiert rien. Voir PKI interforêts.
Les URL de CDP et d'AIA gravées dans les certificats déjà émis, voilà ce qui mord. Ces URL sont fixées à l'émission et ne peuvent pas être modifiées rétroactivement. Elles doivent continuer de se résoudre et de servir des données valides jusqu'à l'expiration de chaque certificat qui les porte.
Le problème de la continuité de révocation
C'est le cœur de tout l'exercice, et la raison pour laquelle la désinstallation naïve échoue.
Chaque certificat émis par pixa-ICA-01 porte des URL de CDP qui indiquent aux parties de confiance où récupérer la LRC. Quand un client valide l'un de ces certificats, il récupère la LRC pour vérifier si le certificat a été révoqué. Mettez l'AC hors ligne et laissez ces URL s'éteindre, et vous avez cassé la vérification de révocation pour chaque certificat valide qu'elle a émis.
Ce qui se passe ensuite dépend entièrement de la partie de confiance. Certains clients font un échec non bloquant (soft-fail) et traitent une LRC injoignable comme « non révoqué ». Beaucoup d'autres font un échec bloquant (hard-fail). Ne présumez pas l'échec non bloquant. L'ouverture de session par carte à puce, plusieurs piles TLS, la validation de signature de code et tout ce qui est durci pour la sécurité ont tendance à traiter une LRC manquante comme un échec. La défaillance est aussi différée et déroutante, parce qu'elle n'apparaît qu'une fois la LRC actuellement en cache expirée, ce qui peut être des jours ou des semaines après que vous ayez mis quoi que ce soit hors service.
Vous avez trois façons de gérer ça :
1. Continuer de signer des LRC jusqu'à l'expiration du dernier certificat émis. Risque le plus faible, mais cela veut dire garder l'AC, ou au moins sa clé et sa fonction de signature de LRC, en vie pendant toute la fenêtre.
2. Publier une seule LRC à longue échéance avant de mettre l'AC hors ligne. Étendez la validité de la LRC pour dépasser l'expiration du dernier certificat émis, publiez-la, et servez-la depuis un emplacement qui survit à l'hôte de l'AC. Le coût, c'est que vous ne pouvez plus rien révoquer pour la durée de vie de cette LRC. Pour une AC que vous éliminez, c'est habituellement acceptable, mais prenez la décision délibérément, pas par accident.
3. Découpler le CDP de l'hôte de l'AC. Déplacez le service de LRC vers un emplacement web ou fichier qui continue de répondre une fois la machine de l'AC partie, et assurez-vous que la LRC finale y réside. C'est le résultat le plus propre quand les certificats émis ont une longue traîne.
[CAPTURE] Console Autorité de certification (certsrv.msc) sur pixa-ICA-01 montrant les propriétés de la LRC publiée avec une date de prochaine mise à jour étendue
Les paramètres de registre pour la validité et le chevauchement de la LRC, ainsi que les détails de placement du CDP, forment un sujet à part. Voir Gestion des LRC, CDP et AIA.
Arrêter l'émission proprement
Une fois la continuité de révocation décidée, empêchez pixa-ICA-01 de prendre du nouveau travail.
Dépubliez les modèles de l'AC pour qu'elle cesse d'accepter des demandes pour eux. Redirigez l'inscription automatique et toute stratégie d'inscription vers pixa-ICA-02. Si vous faites un retrait sur place, vous pouvez cesser d'accepter des demandes tout en continuant de publier des LRC. Si vous allez directement à la mise hors service, publiez votre LRC finale d'abord, puis arrêtez le service.
Sauvegardez la base de données et la clé privée de l'AC avant toute action destructive, et conservez cette sauvegarde durant votre fenêtre de rétention et d'audit. Vous pourriez en avoir besoin pour prouver un état de révocation plus tard, et dans de rares cas pour remonter l'AC uniquement afin de révoquer quelque chose. Voir Sauvegarder et restaurer une AC.
Retirer l'empreinte Active Directory
Une AC d'entreprise se publie dans plusieurs conteneurs sous la partition de configuration. La désinstallation du rôle en retire une partie, mais elle laisse de façon fiable des objets orphelins. Traitez donc le retrait comme une étape manuelle et vérifiée. L'ordre compte, parce que certains objets doivent survivre à d'autres.
- Services d'inscription (
CN=Enrollment Services). Retirer l'entrée de pixa-ICA-01 ici empêche les clients de la découvrir pour l'inscription. Sûr une fois l'émission basculée vers pixa-ICA-02.
- Conteneur CDP (
CN=CDP). Si des certificats émis référencent un CDP LDAP, l'objet LRC ici doit rester jusqu'à l'expiration de ces certificats. Ne le retirez pas trop tôt.
- Conteneur AIA (
CN=AIA). Contient le certificat de l'AC pour la construction de la chaîne. Même règle. Gardez-le tant que des certificats qui s'enchaînent via pixa-ICA-01 sont encore en usage.
- NTAuthCertificates (
CN=NTAuthCertificates). Si cette AC était approuvée pour l'authentification par certificat, la retirer ici retire cette approbation à l'échelle du domaine. Ne la retirez qu'une fois qu'aucun certificat d'authentification de cette AC n'est plus en usage, sinon vous provoquez des échecs d'ouverture de session. Consultez avec certutil -viewstore -enterprise NTAuth et retirez l'entrée précise, pas tout le magasin.
- Autorités de certification (
CN=Certification Authorities). Certificats d'AC racine distribués comme racines de confiance. Retirer une racine ici la rend non approuvée à l'échelle du domaine. C'est la dernière chose à laquelle vous touchez, et seulement pour une racine que vous retirez complètement une fois que chaque certificat sous elle a disparu.
[CAPTURE] ADSI Edit sur la partition de configuration, CN=Public Key Services > CN=Enrollment Services, avec pixa-ICA-01 listée
[CAPTURE] Sortie de certutil -viewstore -enterprise NTAuth listant les certificats d'AC pixa
certutil -dsdel pixa-ICA-01 est la façon prise en charge de retirer les objets d'une AC d'AD, mais comprenez ce qu'elle touche avant de l'exécuter. Dans une forêt multi-AC comme pixa.ca, elle peut atteindre plus que prévu. En pratique, bien des gens retirent les objets délibérément et vérifient chacun dans pkiview.msc plutôt que de lancer une seule commande à l'emporte-pièce.
Si pixa-ICA-01 ou la racine pixa a été publiée dans ranidae.net via l'approbation bidirectionnelle, les copies là-bas sont des objets distincts et survivent à tout ce que vous faites dans pixa.ca. Nettoyez-les dans la forêt ranidae.net comme une étape séparée.
[CAPTURE] Le certificat d'AC pixa présent dans la forêt ranidae.net (conteneur AIA ou NTAuth), atteint via l'approbation bidirectionnelle transitive
Ordre des opérations
- Inventoriez les certificats émis et les dépendances. Décidez : mise hors service, migration ou retrait sur place.
- Cessez d'accepter de nouvelles demandes. Dépubliez les modèles, redirigez l'inscription vers pixa-ICA-02.
- Gérez la continuité de révocation. Publiez une LRC finale ou à longue échéance et confirmez que les emplacements CDP continuent de la servir.
- Laissez expirer ou réémettez les certificats encore valides, selon la stratégie.
- Sauvegardez la base de données et la clé. Conservez la sauvegarde durant la fenêtre de rétention.
- Retirez l'empreinte AD : Services d'inscription d'abord, puis NTAuth, AIA, CDP, et Autorités de certification seulement une fois leurs dépendances disparues.
- Désinstallez le rôle et mettez l'hôte hors service.
- Nettoyez les éléments résiduels : enregistrements DNS, configuration OCSP, NDES, surveillance, les copies interforêts dans ranidae.net, les tâches de sauvegarde.
Les façons dont ça tourne mal
- Tuer l'hôte avant de publier une LRC qui dépasse les certificats émis. La défaillance est silencieuse jusqu'à l'expiration de la dernière LRC en cache, puis elle arrive comme la panne de quelqu'un d'autre.
- Retirer NTAuth ou la racine des Autorités de certification pendant que des certificats d'authentification de pixa-ICA-01 sont encore en usage. Des échecs d'ouverture de session, généralement imputés à tout sauf à l'AC retirée.
- Oublier les copies publiées interforêts. L'AC a disparu de pixa.ca mais reste annoncée dans ranidae.net. Voir PKI interforêts.
- Traiter
certutil -dsdel comme une solution en une étape et retirer des objets partagés dans une forêt multi-AC.
- Jeter la sauvegarde de la base trop tôt et perdre la capacité de prouver ou de modifier l'état de révocation.
Vérifier
pkiview.msc (Enterprise PKI) est le contrôle de santé le plus rapide, avant et après. Confirmez que les clients ne découvrent plus pixa-ICA-01 pour l'inscription, que les LRC valident encore pour les certificats toujours sur le terrain, et que la construction de la chaîne se comporte comme prévu : encore fonctionnelle pour les certificats en circulation, ou intentionnellement brisée pour une racine retirée complètement.
[CAPTURE] pkiview.msc (Enterprise PKI) montrant la santé de l'AC pixa.ca avant la mise hors service, points d'extrémité au vert
