Two quite different requests arrive wearing the same sentence. Someone wants a second issuing authority for high availability, and someone else wants one to separate an exposed population from an internal one. Only one of those is actually solved by a second issuing authority, and it is not the first.
This article sits outside the build sequence, like the post-quantum one. The hierarchy built in this series has a single issuing authority and that is the right shape for most organisations. But the question comes up in almost every engagement once the first authority is running, and it is worth answering properly, because the answer depends entirely on which of the two problems you actually have.
Two things called high availability
A certification authority can be clustered. That is a supported and documented configuration: the role runs as a clustered service, the database and logs live on shared storage, the service’s registry hive is shared between nodes, every node is granted rights on the directory containers the authority writes to, and the authority answers on a clustered name rather than a machine name. Failure of a node moves the authority to the other one and nothing about its identity changes.
The practical constraint is the key. One authority means one private key, and that key has to be available to whichever node is currently running the service. You can import the same key material onto both nodes, and organisations do, but a network hardware security module holding the key once and presenting it to both is the arrangement that does not depend on somebody remembering what they did during the build. If you are clustering an authority, budget for the module.
A second issuing authority is a completely different object. It has its own name, its own key, its own database, its own revocation list and its own place in the directory. It shares nothing with the first one except a parent. Nothing fails over, because there is nothing to fail over to. What you have is two authorities that happen to be capable of similar work.
Clustering gives you redundancy of identity. A second authority gives you redundancy of capability. People ask for the first and get sold the second.
The availability case, examined honestly
Redundancy of capability is not worthless. If two authorities both publish a template and both grant the relevant rights, automatic enrolment will use whichever it finds, so an authority being down does not stop new certificates being issued. That is real and I do not want to dismiss it.
The problem is that it makes the tolerant path redundant and leaves the intolerant one alone. Issuance is remarkably forgiving. Certificates last a year in the design this series built, autoenrollment retries on a schedule, and an authority offline for a week affects only the small population whose certificates happened to fall due in that week, most of whom are inside their renewal window and in no distress. I have watched an issuing authority be down for four days without a single ticket.
Validation is the unforgiving path. Every authentication in the estate depends on a revocation list being reachable, continuously, from everywhere. That is the failure that takes an organisation down in an afternoon, and it is the reason this series put two web servers behind one name before it built the issuing authority at all. If your availability concern is real, it was already answered, and it was answered in the distribution layer rather than in the signing service.
So the honest test is whether your issuance path is genuinely intolerant. There are estates where it is. If certificate lifetimes are measured in days rather than a year, the renewal window shrinks until an outage is immediately visible. If device onboarding gates on issuance, an authority down means nothing new can be built. If you are issuing at a volume where a backlog takes days to clear rather than minutes, an outage has a tail. Those are good reasons. Wanting the architecture diagram to have two boxes is not.
And if the answer to that test is yes, look at clustering first. It preserves one identity, one revocation list, one renewal date, one backup set and one thing to explain, which is a materially smaller operational surface than two independent authorities.
The case that does hold
Separating an exposed population from an internal one is a different argument entirely, and it is the one I would build for.
The reasoning is blast radius. An issuing authority is a machine that holds a key capable of minting identities for your entire organisation. If it is compromised, the remediation is not a rebuild, it is a revocation: the root revokes that authority’s certificate, publishes a revocation list saying so, and every certificate that authority ever signed becomes worthless simultaneously. Then you reissue all of them.
With one issuing authority, that sentence means the whole estate. Every domain controller, every workstation, every internal service, every appliance, in one weekend, while nothing authenticates. With two, split along a boundary that means something, it means only the population served by the compromised one. If the authority that faces something exposed serves a few hundred certificates and the internal authority serves twenty thousand, you have converted an organisational catastrophe into a bad week for one service.
That is what a second issuing authority is genuinely for. It is not a performance decision or an availability decision. It is a decision about what has to be thrown away together.
The same reasoning supports the other legitimate splits, and they all have the same shape. Different administrative teams with different clearance. Different jurisdictions with different legal obligations about where keys may live. Different audit regimes. In each case the question is not who needs certificates, it is who would have to be told, and what would have to be replaced, if this specific key were compromised.
Splitting by object type, which is the version to avoid
Because it comes up: putting user certificates on one authority and computer certificates on another is the arrangement that sounds tidy and buys nothing.
It does not follow a threat boundary. An attacker who controls either authority controls authentication in your domain, and the attacks that actually happen against certificate services are about template misconfiguration rather than about which machine did the signing. You have not reduced the blast radius, you have drawn a line through the middle of it.
What you have bought is a second weekly revocation list that must never lapse, a second authority certificate renewal to remember at its half-life, a second backup set covering identity, database and registry configuration, a second subtree to check in the enterprise PKI view, and a second authority certificate for every relying party to fetch. The maintenance calendar from the operations article roughly doubles, in exchange for a diagram that looks organised.
Split by trust boundary or by lifecycle. Never by object type.
What the second build actually involves
Mechanically it is the issuing authority build repeated, and most of it is unchanged. Two parts are worth naming.
The root has to come back out. Every additional subordinate is another ceremony: locate the machine, power it on, correct its clock, confirm its revocation list is still valid, sign the request, publish, power off. That is the honest cost and it is the one that makes people reconsider. An organisation that finds this ceremony painful will find it painful every time, which is an argument for deciding the shape of the hierarchy before building the first authority rather than after.
The distribution layer, by contrast, needs nothing. Both authorities publish their revocation lists to the same two web servers and both stamp the same public HTTP name into the certificates they issue, because the file names carry a token that expands to the authority’s own sanitised name. Two authorities write two differently named files into the same directory and neither knows the other exists. The token discipline set up on the root pays for itself here without a line of new configuration, which is a fair illustration of why the tokens were worth explaining in the first place.
The selection problem, and the control point nobody uses
This is the part that catches people, and it is the reason the article is worth writing rather than summarising.
A certificate template is a single object in the directory, shared by the whole forest. Publishing it on two authorities does not create two copies. Both authorities issue from the same definition, which means you cannot give the same template a different validity period, a different key length or different permissions depending on which authority handles the request. There is one set of settings and both authorities obey it.
Worse, you do not get to choose which one answers. Automatic enrolment enumerates the authorities registered in the directory, finds those that publish the template and grant the client rights, and picks. A client can be pointed at a specific authority when a request is made by hand, but automatic enrolment is the whole point of the template design and it is not steerable that way.
The lever people miss is that the scoping control is not on the template at all. It is on the authority. Each certification authority object carries its own permissions, and the right to request certificates from it is one of them, documented and doing exactly what it says: gating who may submit a request to that authority. Using it deliberately as the mechanism for steering populations across two issuing authorities is field practice rather than something Microsoft writes down, and I recommend it on that basis. Scope the authority, not the template, and the choice stops being arbitrary.
The cleaner arrangement is to avoid the question. Publish disjoint sets of templates on the two authorities, so that for any given request exactly one authority is capable of answering. Selection becomes deterministic because there is nothing to select, and it falls out naturally from the boundary you split on in the first place. If your two authorities serve genuinely different populations, they should be issuing genuinely different templates, and if they are not, the split is probably not real.
The decision you already made
There is a small, irritating detail in all of this that belongs to the very first article in the series.
An authority named for the organisation and its role, with no qualifier, assumes there will only ever be one. You cannot rename a certification authority. So the day you add a second one, you either give it a name that sits awkwardly beside the first, or you accept that the original is now permanently ambiguous, or you rebuild the original, which is the option nobody takes. A name chosen in the first hour of the first build quietly decides how comfortable this article is to act on three years later.
I am not suggesting everyone name their first authority as though a second is coming. Most estates never build one and a speculative qualifier in a name that appears in every certificate for a decade is its own small cost. But if you already know a boundary exists, name for it on day one. It is free then and it is unavailable afterwards.
Where I land is narrow. If the concern is availability, test whether your issuance path is actually intolerant, and if it is, cluster the authority you have rather than building a second one. If the concern is that one key currently covers populations that should not fall together, build the second authority, split the template sets so selection is deterministic, scope the authorities themselves rather than the templates, and add both revocation lists and both renewal dates to the calendar the operations article told you to write. And if the concern is that the diagram looks lonely, the answer is that every authority you add is another key to protect, another list to publish and another date to miss.
On-Prem PKI
‹ Previous: [P 8] Post-Quantum Signing in AD CS: What ML-DSA Changes and What It Does Not
Next: [P 10] Private PKI and the Public Web PKI Are Different Systems ›
