A well-built private PKI needs almost no attention, which is exactly what makes it dangerous. There are two dates in its entire life that matter, both are years apart, and missing either one takes down authentication across the estate in a single moment with no warning and no degradation.
That is the operating model, and it is unusual enough to be worth stating plainly. This is not a system with a daily health routine and a queue of tickets. It is a machine that runs itself for a year at a time, punctuated by obligations that arrive too infrequently for anyone to build a habit around. Everything in this article exists to make those obligations survive staff turnover, because the person who built the hierarchy is very often not the person who will be holding it when the deadline arrives.
Trust distribution is not a build step
Publishing the root into the forest solves the problem for domain members and creates the illusion that the problem is solved. Every joined machine trusts the hierarchy automatically, and it keeps working as machines are built and rebuilt, which means nobody thinks about it again.
Everything else is a separate and permanent piece of work. The Linux hosts, the appliances, the printers doing network authentication, the mobile devices managed by a platform that has its own trust store, the contractor laptops, the monitoring system that checks your internal HTTPS endpoints, the container images that were built six months ago from a base that has never heard of your certificate authority. None of them gets the root from a group policy object. Each has its own mechanism, and the common failure is not that these are hard, it is that nobody owns the list.
There is a sequencing rule inside this that is easy to violate. Trust has to arrive before the certificates that depend on it. Issue a certificate to a service, point clients at it, and then discover that a population of those clients does not trust the issuer, and you have created a visible outage out of an invisible omission. When a new class of relying party enters the estate, the question is not whether it needs a certificate. It is whether it already trusts the thing that will issue one.
Distributing trust is a standing obligation with no completion date, because the estate keeps acquiring things that have never heard of you.
Backup is three things, and people keep only two
A certificate authority has three distinct pieces of state, and losing any one of them produces a different and equally unpleasant recovery.
The first is the identity: the private key and the certificate. Lose that and the authority is gone. Nothing signed by it can be replaced by a rebuilt authority, because a rebuilt authority is a different authority with a different key, and every certificate in the estate would have to be reissued under a new chain.
The second is the database: every certificate ever issued, every revocation, every pending request. This is what lets a restored authority publish an accurate revocation list. Restore an authority without its database and you have an authority that can sign new things and has forgotten what it has already disowned, which is a quietly serious condition, because a revoked certificate becomes valid again.
The third is the configuration, and it is the one that gets lost. Every setting made after installation, the distribution points, the revocation schedule, the validity ceiling, the audit filter, lives in the registry and is not captured by the certificate services backup. Restore the first two onto a fresh machine and you get an authority that signs correctly, publishes to nowhere, and stamps distribution points into certificates that point at the default locations from installation. It works well enough to be believed and is wrong in the one way that matters.
A virtual machine snapshot appears to solve all three at once, and for the offline root it is genuinely the primary protection, because that machine is a sealed artefact rather than a running service. For the issuing authority it is a supplement and not a replacement, for a reason that has nothing to do with completeness: the snapshot lives on the same hypervisor storage as the machine it protects. A storage failure, or ransomware reaching the virtualisation platform, takes both. The certificate services backup is small, portable and can sit somewhere entirely unrelated, which is the property you actually need.
Whatever you write, write it somewhere else afterwards. And be careful with the credential that protects it, because the tooling has a defect worth knowing: if the expression producing the password fails, the backup is taken anyway, unprotected, without an error. A backup you believe is encrypted and is not is worse than no backup, because you will store it accordingly.
The two dates
Everything else in the maintenance schedule is derived. These two are the schedule.
The first is the annual revocation list on the offline root. It cannot be automated, because the machine that has to sign it is deliberately unreachable. When it lapses, clients cannot confirm the issuing authority is still trusted, so they refuse every certificate the issuing authority ever signed, all at once, everywhere. Nothing has expired. Nothing has been revoked. Authentication simply stops. This is the single most damaging thing that can go wrong in a private PKI and it is caused by a forgotten calendar entry rather than by any technical failure.
Which is why the margin matters more than the schedule. A revocation list that runs for fifty-two weeks with a generous overlap gives you weeks past the nominal date before anything breaks, and a reminder set a couple of weeks early turns a hard deadline into a comfortable one. A three-day overlap, which is a common default, converts a missed reminder into a weekend outage. The overlap costs nothing, the file and the schedule are unchanged either way, and it is the cheapest insurance in the entire design.
The second date is the renewal of the issuing authority’s own certificate, at half its life rather than near the end. As covered earlier in this series, an authority cannot issue a certificate that outlives its own, so an issuing authority approaching expiry silently begins shortening everything it signs. Renew at the halfway point and nobody ever observes it. [P 6.2] Build Sheet: Renewing the Issuing CA, and the Root is the procedure for doing it.
Both dates belong in a calendar owned by a role rather than a person, with the consequence written into the entry rather than assumed. “Renew root CRL” means nothing to whoever inherits it in four years. “Renew root CRL. If this is missed past the hard date shown, all certificate authentication in the domain fails simultaneously” means a great deal.
What to actually watch
The enterprise PKI view is the best diagnostic in the product and a poor monitor, because it requires somebody to open it. It walks every authority, checks every distribution point, and names the exact location that is failing. Run it monthly and during every incident, and do not mistake it for something that will tell you when it goes red.
What deserves a real alert is short. The time remaining on each published revocation list, measured against its next update rather than against a calendar assumption, alerting well before the overlap is consumed. The reachability of the distribution URL, checked from outside the network rather than from a server that shares a subnet with the web servers. And, specifically, the two web servers checked independently by address rather than through the shared name, with the files compared, because the failure this architecture is designed against is one node serving an older list than the other while both return a healthy response.
The revocation list’s size is worth trending too, quietly. Lists grow as certificates are revoked and shrink as revoked certificates pass their expiry. If yours is growing steadily rather than plateauing, something in the estate is revoking constantly, and there are external consumers with hard size and timeout limits that will fail before you notice a bandwidth cost.
Renew, or rebuild
Eventually something forces a decision, and the choice is narrower than it looks. Renewal keeps the authority’s identity and extends its life, and if you renew with the existing key everything already issued continues to chain without interruption. That is the right answer for the ordinary case of a certificate approaching its half-life, and it should be routine rather than a project.
Rebuilding is a different act with a different cost, and the honest test for whether you need it is whether the thing you want to change is one of the permanent decisions from the first article in this series. A different name, a different key length, a different algorithm, a different distribution point: none of those can be renewed into existence. Post-quantum signing is the current example, because an authority cannot be migrated to it in place, so adopting it means a parallel hierarchy and a deliberate trust migration rather than an upgrade.
When that day comes the work is not the build, which you have a documented procedure for. It is running two hierarchies side by side while trust is distributed for the new one, certificates are reissued from it, and the old one is finally retired with its revocation list kept alive until the last certificate it signed has expired. Plan the overlap, not the cutover.
The deliverable that keeps all of this alive is not a monitoring dashboard. It is a one-page calendar naming each obligation, its frequency, the hard date at which it becomes an outage, and the role that owns it, written so that somebody who has never seen this hierarchy can act on it. That document is the difference between a PKI that is still working in five years and one that fails on a Tuesday for reasons nobody present can explain. The build sheet that follows produces it, along with the backups and the trust distribution that make it worth having.
On-Prem PKI
‹ Previous: [P 5.1] Build Sheet: The Template Set, Autoenrollment, and Manual Enrollment
Next: [P 6.1] Build Sheet: Trust Distribution, Backup, and the Maintenance Calendar ›
