Everything in this series so far has been about building a hierarchy. This one is about removing the hierarchy you are replacing, which is a harder problem, is documented in the wrong order, and is where most of the damage in a PKI project actually happens.
Almost nobody builds a private certificate authority into an empty forest. There is usually one already, standing on an operating system that went out of support, built by somebody who left, holding a key nobody can account for. My position on those is consistent and I will state it plainly: I do not upgrade a certificate authority. I build a new one properly and retire the old one deliberately, because the permanent decisions from [P 1] Why You Still Run a Private CA are permanent, and inheriting somebody else’s are the only ones you cannot revisit.
That position deserves the alternative named rather than waved at, because there is a supported one. Microsoft documents a migration procedure that moves a certificate authority to new hardware and a new operating system while preserving its key, its name and its database. It works, it is the right answer in some situations, and it is what most people mean when they say they upgraded their PKI.
What it cannot do is change any of the decisions from the first article in this series. The name is the name. The key length is the key length. The distribution points are whatever somebody typed in 2014, frozen into every certificate the authority has ever issued. A migration carries all of that forward onto a supported operating system, which solves the platform problem and none of the design ones, and leaves you maintaining somebody else’s permanent decisions for another decade. When the thing wrong with a hierarchy is its age, migrate it. When the thing wrong with it is how it was built, and it usually is, migrating is how you inherit the problem rather than end it.
Which makes retirement the other half of the job, and the half that gets a paragraph in most guides.
The uninstall is not the thing
Microsoft documents this properly and the procedure runs to nine steps. Removing the role is the fifth of them, and it is close to the least consequential thing you do.
Here is what the uninstall actually removes from the directory: one object. The enrolment services entry, which is what clients read to discover that an authority exists and will issue to them. Removing it stops new enrolment, which is genuinely useful. Everything else stays exactly where it was, and it stays deliberately.
An enterprise authority creates four objects in the configuration partition when it is installed. One in the authority information container, holding its certificate. One in the distribution point container, holding the revocation list it publishes to the directory. One in the certification authorities container, which is what places it in the forest’s trust. And the enrolment services object. Only the last is removed on uninstall, because the other three are what outstanding certificates depend on to be validated at all, and there are always outstanding certificates.
The authority is a service you can switch off in an afternoon. The certificates it signed are somebody else’s problem for another year.
That asymmetry is the whole of this article. Every mistake in a retirement is some version of forgetting that the certificates carry on after the machine that issued them has gone, and that they carry references to locations which have to keep answering.
The documented order will take you down
The first three steps of the official procedure are: revoke every certificate the authority has issued, with a reason of cease of operation. Extend the revocation list publication interval past the remaining lifetime of everything you just revoked. Publish that list.
Every one of those instructions is correct. Performed in that position, they are an outage. You have just told the entire estate that every certificate this authority ever signed is invalid, and you have published a revocation list that says so with a long life, which is precisely so that the statement cannot be walked back by waiting.
The procedure is not wrong. It is written for a different scenario from the one you are almost certainly in. It assumes the authority is being decommissioned because it is finished: the certificates are no longer wanted, and the point of the exercise is to make sure none of them can be used again. That is the compromise case, and in the compromise case revoking first is exactly right.
A planned replacement is the opposite situation. The certificates are very much still wanted, right up until the moment their replacements are installed and working, and the retirement succeeds precisely to the extent that nobody notices it happening. So the revocation step moves to the end, after replacements are deployed and verified, and in a great many replacements it does not happen at all, because letting the last certificates expire on their own schedule achieves the same end state with no cliff in it.
Decide which of those two jobs you are doing before you touch anything, because the correct order is nearly reversed between them.
Three retirements, not one
The word covers three jobs of quite different sizes, and conflating them is how a two-week piece of work turns into a quarter.
Retiring one issuing authority beneath a root you are keeping is the small one. Trust does not move, because the anchor does not move. Relying parties need nothing. What you are doing is moving issuance from one subordinate to another and then removing the first, and the overlap is bounded by the longest certificate the old one signed.
Retiring an entire hierarchy is a different animal, because the anchor changes. Every relying party has to be given the new root before anything it signs is worth having, which is the standing obligation from [P 6] Operating a PKI being paid a second time, in full, while the old hierarchy stays alive. And the old root has to keep publishing a revocation list until the last certificate beneath it has expired, which for a subordinate issued a five-year certificate can be years after everyone has stopped thinking about it.
The third is the one people actually bring me, and it is the abandoned hierarchy that is nonetheless still issuing. Somebody set it up, it worked, nobody documented it, the team changed twice, and it now sits there quietly signing certificates for a population that nobody can enumerate. It is the same procedure as the first two with the entire discovery phase moved to the front and made much harder, because the authority can no longer tell you what it has done.
There is a mechanism that appears to make the second case much cheaper, and it is worth knowing why I do not use it. Cross-certification lets two authorities issue certificates to each other so that entities in one hierarchy are trusted by the other, with the trust path running sideways rather than up. Windows implements it as qualified subordination, with a dedicated template, a constraints file and a directory attribute to hold the result. Applied to a migration, the old root cross-certifies the new one and every relying party that already trusts the old anchor accepts the new hierarchy immediately, without you distributing anything.
The catch is that it does not remove the work, it defers it. You are retiring the old hierarchy, so the new root has to reach everything eventually anyway, and now the cross-certificate has to be unwound as well. In the meantime you have added an artefact with its own validity and its own revocation, and you have created more than one valid path from a leaf to a trusted root. Different clients resolve that differently. Path building is the least consistently implemented part of certificate validation, and the reliable symptom is a certificate that verifies on Windows and fails on a Java or OpenSSL client with an error that explains nothing.
Cross-certification is built for a problem that is not this one: two organisations that need to trust each other’s certificates indefinitely, a merger, or a partner hierarchy you want to trust for certain names and purposes and nothing else. That is federation, and it is permanent by design. A retirement is temporary by definition, and paying a permanent cost to make a temporary phase cheaper is a poor trade.
What you can know, and how you find out when you cannot
A functioning authority, however old, is a gift, because it holds a database of everything it has ever issued. You can enumerate every certificate that has not yet expired, with its subject, its template and its expiry date, and that list is your entire scope of work. A retirement with that list in hand is a project with a known size and a known end date. Nothing else in this article is difficult once you have it.
When the authority cannot tell you, the estate has to. That means asking the question from the other end: not what did this authority issue, but what in this organisation is holding a certificate that chains to it. The directory knows which authorities are registered in the forest. Group policy knows which populations were told to enrol automatically. The domain controllers know what they are presenting for authentication. The network access servers know which issuers they accept. And the endpoints themselves know, if you are willing to go and ask all of them, which is a scripted sweep rather than an investigation.
The uncomfortable finding in the abandoned case is almost always the same: something is still enrolling. An authority that has been forgotten but is still issuing has a client somewhere that never stopped asking, and if you remove the authority before you find out what it is, you break that thing and nobody left in the building will know why. Find the enrolment before you stop it.
The real kill switch, and the one people reach for instead
There is a specific store in the forest that determines whether an authority’s certificates are accepted for logging on to the domain. Being in it is what makes an authority trusted for authentication, as distinct from merely being trusted. Removing an authority from it is the switch that ends its ability to authenticate anybody, and it is separate from every other step in this procedure. Uninstalling the role does not do it. Removing the directory objects does not do it. It is its own action and it needs to be on the checklist explicitly, or you will finish a retirement having left the old authority still able to mint domain credentials, which is the exact condition you were trying to end.
The thing people reach for instead is the power button, and it is the worst available option. A certificate authority that has simply been switched off has lost none of its authority. Its certificate remains in the forest’s trust. Its entry in the authentication store remains. Its root remains in every trusted root store in the estate. Every certificate it issued remains valid and will be accepted. And its revocation list, the one thing that would eventually have told the world something was wrong, quietly expires, at which point validation fails everywhere at once for reasons that lead investigators to a machine that has been off for six months.
Switching it off gives you every consequence of a dead authority and none of the benefits of a retired one. If you take nothing else from this article, take that.
What is left behind after you have finished
The uninstall deliberately leaves the machine holding everything needed to bring the authority back: the database, the certificate, and the private key, still sitting in whichever provider was used to generate it. That is a sensible default for an administrator who is moving an authority between servers and a poor one for an administrator who has just spent a fortnight ending it.
The key is the part that matters and the part that is forgotten, because it is not a file in an obvious place. An authority’s private key can outlive the authority, the server’s role, the administrator and the project, and a copy of it is a copy of the organisation’s ability to issue certificates that everything still trusts. Retirement is not finished until you have accounted for it, and account for is doing real work there: know where it was, know what happened to it, and be able to say so.
The directory objects are the other half. The ones the uninstall left in place have to come out eventually, but only once nothing depends on them, and there is a real order to it because deleting the template definitions while any authority still exists in the forest is a self-inflicted injury with a recovery procedure attached.
The deliverable, as with everything else in this series, is not the completed task. It is a written record: what this authority issued, to whom, until when, what replaced it, what became of its key, and the date after which its revocation list no longer needs publishing. Retirement is the one PKI activity that produces no artefact anyone can point at afterwards, which is precisely why it has to produce a document instead. The build sheet that follows works through it in the order that does not break anything.
On-Prem PKI
‹ Previous: [P 10] Private PKI and the Public Web PKI Are Different Systems
Next: [P 11.1] Build Sheet: Decommissioning an Enterprise CA ›
