A root certificate authority spends almost its entire life switched off. People hear that and conclude it has no operating model. It has exactly one, it runs on an annual clock, and forgetting it is the most reliable way to take down an estate that has nothing visibly wrong with it.
The design of an offline root is unusual because almost every decision is made in service of a machine that will not be running when the decision matters. You are configuring something that has to be correct on the day it is built, correct again in a year when somebody powers it on for twenty minutes, and correct in a decade when the person who built it has left. That is a different discipline from configuring a server you can log into on a Tuesday and adjust. It rewards deliberation and punishes cleverness.
Why the root leaves the domain
The root is a standalone certificate authority in a workgroup, not an enterprise authority joined to Active Directory, and the reason people usually give is a security instinct rather than an argument. The argument is better than the instinct. A domain-joined machine is a participating member of a distributed system that assumes it participates. Its computer account password rotates on a schedule the machine takes part in, and a box that has been powered off in a cupboard for eleven months has taken part in none of it. The first thing that happens when you power it on for its annual appointment is that it cannot establish a secure channel, which means the domain credentials it was configured under may not log you in. You have created a machine you cannot get into, on the one day of the year you need it, in order to perform the one task that keeps the estate working. A workgroup machine with a local administrator account has no such dependency, and that is the whole of it.
The second consequence of being off the network is quieter and catches people out. The machine has no time source. Nothing corrects its clock, and a virtual machine that has been suspended for a year will come back with a view of the current date that ranges from optimistic to absurd. Every certificate it signs and every revocation list it publishes is stamped from that clock. A revocation list issued with a start date in the past is a revocation list that is already partly spent, and one issued with a start date in the future is a revocation list that no client will accept at all. Correcting the clock is not housekeeping before the real work. It is the first step of the real work, and it belongs in the runbook above everything else.
There is a third effect of standalone that is worth naming because it is routinely attributed to the wrong setting. A standalone certificate authority has no certificate templates. Templates are an Active Directory construct, and an authority that cannot see the directory has no access to them. That, and not any policy file directive, is what stops a root issuing end-entity certificates to anybody who asks. You will see root configurations that carry a directive suppressing default templates, with a comment explaining that it prevents the root issuing certificates it should not. The directive is harmless and I leave it in place as a statement of intent, but it applies to enterprise installations and does nothing here. The root cannot issue from templates because there are none to issue from. It signs exactly one thing in its life, and that is the certificate of the authority beneath it.
What offline actually means
Offline is a discipline, not a checkbox, and the gap between the two is where most implementations quietly fail. In the design I build, the root is a virtual machine with no network adapter attached at all, not a disabled adapter and not an isolated network segment. Files move in and out through a hypervisor shared folder, which is deliberate: the transfer mechanism is a property of the virtualisation platform rather than a property of the guest, so there is no path from the network into the machine even if someone misconfigures something later.
Virtual rather than physical is a practical choice and I make no apology for it. A physical root that lives in a safe is more satisfying and is genuinely appropriate where an attached hardware security module or a policy requirement demands it, but for most organisations it introduces a machine that must be stored, powered, patched and eventually replaced, and the failure mode is that it becomes the box nobody can find. A virtual root whose disk is exported and held on encrypted removable media, with the running copy powered off between appointments, gives you the same isolation with a recovery story you can actually rehearse.
If a network adapter is attached temporarily for any reason, remove it again immediately and write down that it happened.
What I care about more than the form factor is that the isolation is stated as a rule with an exception process rather than assumed as a property. Someone will eventually want to attach an adapter, to apply updates or to copy a file the shared folder is refusing to move. The answer is not that it is forbidden, because in practice it will happen. The answer is that it is a documented exception with a defined end, because the security of the entire hierarchy rests on the private key of this machine never having been reachable, and that claim is only as good as your ability to say when it was and was not true.
The one obligation that never sleeps
Here is the part that turns an architectural diagram into an operating commitment. The root publishes a certificate revocation list, and that list has an expiry date. It is the only artefact the root produces on a recurring basis, and it exists to answer one question that clients ask constantly: is the certificate of the issuing authority still good? Every time anything validates a certificate anywhere in your estate, the chain walks up to the issuing authority, and checking that authority’s status means fetching a list signed by a machine that is switched off.
When that list expires, nothing about your certificates changes. They remain cryptographically valid, correctly issued, and entirely trustworthy. What changes is that relying parties can no longer confirm the issuing authority has not been revoked, and a validation that cannot complete is a validation that fails. The symptom is authentication breaking across unrelated systems simultaneously, with no configuration having changed and no certificate having expired, which is precisely the shape of outage that consumes a day before somebody thinks to look at a revocation list nobody has considered since the build.
So the revocation list lifetime is a design decision about how often you are willing to visit this machine. I set it to fifty-two weeks, which converts the obligation into a single annual appointment. That is deliberate and it is a trade. A shorter lifetime means more frequent visits and a smaller window of stale information, which on a root that revokes essentially nothing buys you very little. A longer lifetime is tempting and I would resist it, because the appointment is the only thing keeping the machine in anyone’s mind at all, and an obligation that recurs less often than annually will be forgotten by whoever inherits it.
The parameter that matters more than the lifetime, and gets a fraction of the attention, is the overlap. The overlap extends the validity of the published list beyond the point at which a replacement was due, and it is the entire safety margin on a manual task performed once a year on a machine that has to be located, powered on and time-corrected first. Set it to a few days and you have given yourself a long weekend of grace. If the person who owns the task is on leave, or the reminder lands during an incident, or the machine takes longer to find than expected, the margin is gone and the outage is real. I now set it in weeks rather than days, because the cost is small and specific. The list is the same size and the publication schedule is unchanged. The one thing that does move is the window in which Windows clients pre-fetch the next list, which widens rather than narrows, because that window is computed from the gap between publication and expiry. A generous overlap turns a hard deadline into a soft one, and every operational thing I have learned about PKI says that is worth doing wherever the mechanism allows it.
Delta revocation lists have no place on a root and I disable them explicitly. A delta list is an optimisation for an authority that revokes frequently enough that republishing the whole list is expensive. A root revokes one class of certificate, belonging to the authority directly beneath it, and it does so approximately never. Advertising a delta location that will never be populated is a lookup that can only fail, and I would rather the extension not be there at all.
The key, and what protecting it actually costs
Without a hardware security module the private key lives on the machine, protected by the operating system and, in practice, by the physical and administrative controls around the virtualisation platform. That is an honest position and it is where most organisations of moderate size land. A hardware module changes the claim from the key is on a machine we control to the key cannot be extracted from this device, and it can be configured so that every cryptographic operation requires an administrator to authenticate. It is the right answer where the organisation has a regulatory driver or a genuine adversary model, and it introduces a dependency you have to plan for, because the module has to be installed and configured before the authority is created and it becomes a permanent part of the recovery story.
Whichever you choose, backup is three separate things and treating it as one is a common way to discover you have nothing. There is the private key with its certificate, there is the authority’s database, and there is the registry configuration that holds every setting made after installation, including the distribution point URLs that took the longest to get right. Standard backup tooling captures the first two and silently omits the third. Restoring key and database onto a fresh machine gives you an authority that signs correctly and publishes to nowhere, which you discover at the worst possible moment.
The end of the root, planned from the beginning
The root certificate has a validity period, and unlike almost everything else in the design, reaching the end of it is not an event you can absorb quietly. The convention is to renew a certificate authority certificate at half its life, which on a twenty-five year root puts a serious conversation somewhere around year twelve. Renewing with the existing key pair is the gentle path: the certificate gains a later end date, everything already issued continues to chain correctly, and the disruption is close to zero. Renewing with a new key pair is a different operation, because it splits the chain, generates a new revocation list, and requires both the old and new paths to validate for as long as anything issued under the old key survives.
What I would actually plan for, though, is that the root does not reach its expiry date as a cryptographic object at all. A four thousand and ninety-six bit RSA root signed today has a validity that runs well into the middle of the century, and the algorithm will not. Post-quantum signing arrived in Active Directory Certificate Services this year, and the significant detail for this article is that it cannot be applied to an authority that already exists. Adopting it means building a new hierarchy alongside the old one and migrating trust deliberately. That is not a reason to shorten the root’s validity, because the certificate’s dates and its cryptographic relevance are separate clocks. It is a reason to hold the design loosely, and to make sure the thing you build is documented well enough that its successor can be built by someone reading your notes rather than reverse-engineering your registry.
All of which is to say that the root is not a server you install. It is a set of commitments with an annual appointment attached, and the build sheet that follows this article is really a way of making those commitments concrete: a policy file that fixes what cannot be changed later, a set of distribution points that must be right before anything is signed, a revocation list with a generous margin, and a machine that goes back in the cupboard when it is done.
On-Prem PKI
‹ Previous: [P 1] Why You Still Run a Private CA, and What Two Tiers Actually Buy
Next: [P 2.1] Build Sheet: The Offline Root CA ›
