Almost everything in a certificate authority can be changed later. A handful of things cannot, and you choose all of them in the first hour, before you have issued a single certificate. This series is about that hour, and about the decade that follows it.
Most writing about Microsoft PKI is a click-path. Install the role, accept the defaults, admire the green ticks in the console. That is the easy part, and it is the part that has been written a thousand times. What is missing is the argument underneath it, because a certificate authority is not really a server role. It is an assertion of authority: a claim that this organisation vouches for the identity of this machine, this person, this service, and that the claim can be checked by anyone who cares to look. The technology is a means of publishing that claim. The design decisions are about who holds the authority, how long the claim stands, and what happens when you need to withdraw it.
That framing changes what matters. It stops being a question of which checkbox to tick and becomes a question of what you are committing to, and for how long. A root certificate authority with a twenty-year life is a twenty-year commitment to a name, a key length, a hash algorithm, and a set of URLs. Nothing about the install wizard signals that. The wizard presents those choices in the same visual register as the database file path, and only one of those is genuinely reversible.
The 2026 objection, answered first
Before any of the design argument is worth your time, there is an objection to clear, because I hear it in nearly every engagement now. The objection is that on-premises PKI is legacy, that Microsoft is retiring Active Directory Certificate Services, and that Intune Cloud PKI makes the whole conversation moot. It is worth taking seriously, and it is wrong in three separate ways.
The retirement claim is the easiest to dispose of. AD CS does not appear on any Windows Server deprecation or removal list, and Microsoft’s own definition of a deprecated component is instructive: something that still ships, is still supported in production, and still receives updates, but is no longer in active development. AD CS does not even meet that lower bar for concern. The date circulating in vendor marketing, the one that produces headlines about AD CS ending in 2027, is Windows Server 2016 reaching extended end of support on the twelfth of January that year. That is an operating system lifecycle date. It means the 2016-era certificate authority in your rack needs rebuilding onto a supported platform, which is a real project with a real deadline. It does not mean the role is going away, and the vendors converting one into the other are selling something.
The second answer is more interesting, because it runs the other direction entirely. AD CS is not merely surviving, it is where Microsoft shipped post-quantum certificate issuance first. A certificate authority running Windows Server 2025 with the May 2026 security update can sign with ML-DSA, the lattice-based signature algorithm standardised as FIPS 204, across root, subordinate, enterprise and standalone roles. The constraints are real and worth knowing before anyone gets excited: it is signature-only, so it cannot serve encryption or key exchange, key storage must be a CNG provider because legacy providers are unsupported, enrolment is limited to the certificates console and the command line, and an existing certificate authority cannot be migrated in place. Adopting it means standing up a parallel hierarchy. But the direction of travel is unmistakable, and Cloud PKI, which is RSA-only today, has no answer to it. If your cryptographic roadmap has opinions about the next decade, those opinions currently live in AD CS.
Cloud PKI retires your NDES server. It does not retire your PKI.
The third answer is the one that costs organisations money when they get it wrong. Intune Cloud PKI is a genuinely good service and I recommend it often, but its scope is narrow and precise: it issues end-entity certificates, over SCEP, to devices that are enrolled in mobile device management. That is the whole envelope. Every organisation that assumed it could decommission its certificate authority discovers the same list of things it cannot do. Domain controller certificates for Kerberos authentication and secure LDAP. Internal TLS for the hundred services that terminate HTTPS on your own network. Code signing. Smart card logon. Certificate-based authentication for every device that will never be enrolled in Intune, which in most estates means the printers, the cameras, the badge readers, the building management system, the medical equipment, and every switch and access point doing 802.1X. Cloud PKI does not reach any of it, and no announced roadmap suggests it will.
What Cloud PKI genuinely does retire is the Network Device Enrolment Service, which is a real prize because NDES is the most uncomfortable component in the traditional design. What it does not retire is the authority underneath. The honest position, and the one this series is built on, is that a modern estate runs both: a private certificate authority for everything it owns, and Cloud PKI for the managed endpoint fleet, with the two joined at a signing ceremony we will get to at the end.
What an offline root actually buys
The two-tier hierarchy is the default recommendation in every deployment guide, including mine, and it is the right default. But it is usually justified with hand-waving about security, and the hand-waving obscures a much sharper claim. An offline root buys you exactly one thing, and it is worth stating precisely, because knowing what it does not buy is how you avoid designing around a protection you do not have.
It buys you this: the private key of your trust anchor is not reachable from the network. When something goes wrong on the issuing authority, and it will, the attacker holds the ability to issue certificates until you notice and revoke. What they do not hold is the anchor itself. You can revoke the issuing authority’s certificate, stand up a replacement, sign it with a root that was never exposed, and the trust you distributed to every domain member, every appliance, every trust store, remains valid. Without the offline root, the same incident means re-establishing trust everywhere, which in a large estate is not an incident response, it is a project with a steering committee.
That is the whole benefit. It does not make revocation faster. It does not protect the issuing authority from anything at all. It does not reduce the risk from a badly configured certificate template, which as we will see is a far more likely route to compromise than anyone stealing a root key. And it emphatically does not remove the operational burden, because a root that is switched off still has one live obligation: it must publish a revocation list, on a schedule, forever. A powered-down machine in a safe is not a machine with no maintenance. It is a machine with an annual appointment that nobody has put in a calendar, and the failure mode when that appointment is missed is the most common self-inflicted PKI outage there is.
The third tier, when people propose one, is nearly always proposed for the wrong reason. A policy certificate authority in the middle is not additional security. Microsoft describes it accurately as a way to separate classes of certificate by assurance level or by geography, and notes it can be online or offline as the separation requires. That is a policy boundary, and it is a legitimate thing to want. So the test is simple and I apply it without exception: name the boundary. If you can articulate which classes of certificate are being separated and why they must not share an issuer, build the tier. If the answer is that three tiers sounded more secure than two, you are buying a second offline machine, a second annual revocation appointment, and an extra certificate in every validation chain, in exchange for nothing.
The worked example, once, for the whole series
Everything from here to the end of the series is built against one estate, and I use the same names in every article rather than switching between placeholders. The domain is catsnackjack.com. The root authority is CatSnackJack Root CA, standalone, in a workgroup, on a host named ROOTCA that spends its life switched off. The issuing authority is CatSnackJack Issuing CA, an enterprise subordinate on a host named SUBCA. Revocation lists and authority certificates are published over HTTP at pki.catsnackjack.com, served by two web servers named PKI-WEB01 and PKI-WEB02 sitting behind that one name.
The names are invented. The design is not. Substitute your own organisation and domain and every command in the build sheets runs unchanged. Here is the whole reference in one place, so that nothing later in the series needs to stop and reintroduce itself.
One deliberate simplification worth naming before anyone writes in about it. Using the registered public name flat as the Active Directory domain is not what Microsoft recommends. The documented guidance is a subdomain of a name you own, corp.catsnackjack.com rather than catsnackjack.com, which avoids split-brain DNS and guarantees the namespace is unique without touching any existing DNS infrastructure. That decision belongs upstream of the PKI and is nobody’s to make at build time, so this series takes the flat form purely to keep the distinguished names in the commands short enough to read. Wherever a domain appears in a distinguished name, every label separated by a dot becomes its own domain component, so a forest rooted at corp.catsnackjack.com reads DC=corp,DC=catsnackjack,DC=com and nothing else changes.
| Element | Value used throughout |
|---|---|
| Active Directory domain | catsnackjack.com |
| Platform | Windows Server 2022 or 2025 |
| Root CA | CatSnackJack Root CA, standalone, workgroup, offline. Host ROOTCA |
| Issuing CA | CatSnackJack Issuing CA, enterprise subordinate. Host SUBCA |
| CDP and AIA base URL | http://pki.catsnackjack.com/pki/ |
| Web servers | PKI-WEB01 and PKI-WEB02, both behind pki.catsnackjack.com |
| CA database paths | D:\RootCA\DB on the root, D:\PKI\DB on the issuing CA |
| Keys and hash | RSA 4096 on both authorities, SHA-256. End-entity templates RSA 2048 |
| Root validity | 25 years, issuing a 5 year certificate to the subordinate |
| Root revocation list | 52 week publication period, 6 week overlap, delta lists disabled |
| Issuing CA revocation list | 1 week publication period, 3 day overlap, delta lists disabled |
| End-entity ceiling | 1 year, enforced at the authority |
| Template names | CSJ prefix: CSJComputerAuthentication, CSJUserAuthentication, CSJDomainController, CSJWebServer, CSJWebServerShared |
Hostnames are role-based, uppercase and unqualified. Certificate authority common names are organisation-scoped and describe the role rather than the machine, which matters more than it sounds: the common name appears in every certificate the hierarchy will ever issue, and there is no reason to publish the name of a server that is supposed to be unreachable.
The decisions you only get to make once
Here is the part of the design that deserves a meeting, a document, and a signature. Every value in the table below is embedded into certificates at the moment the authority is created, and the cost of changing any of them afterwards is not an edit. It ranges from rebuilding the issuing authority and reissuing every certificate it ever produced, to rebuilding the entire hierarchy and redistributing trust to everything that consumes it.
| Decision | Example value | Cost of changing it after the build |
|---|---|---|
| Root CA common name | CatSnackJack Root CA | Complete rebuild. Every certificate in the chain becomes untrusted. |
| Issuing CA common name | CatSnackJack Issuing CA | Issuing CA rebuild. Every end-entity certificate must be reissued. |
| CDP and AIA base URL | http://pki.catsnackjack.com/pki/ | Issuing CA rebuild. The old URL must stay resolvable until the last certificate carrying it expires. |
| Key length, each CA | RSA 4096 | Rebuild of that CA, and of the root means the whole hierarchy. |
| Hash algorithm | SHA-256 | Rebuild of that CA. |
The URL row is the one that catches experienced people, because it is the only entry that is not obviously a cryptographic decision. It is a DNS name and a path, the kind of thing an infrastructure team changes on a Tuesday. But those characters are written into every certificate the authority signs, in the extensions that tell a relying party where to fetch revocation information and the issuer’s own certificate. A certificate issued in 2026 with a five-year life will still be asking for that exact URL in 2031. Change the name, retire the host, let the DNS record lapse, and you have not broken a web server. You have broken revocation checking for every certificate still carrying it, and the symptom will be authentication failures in systems nobody connected to a decommissioned web server.
Those URLs are not infrastructure. They are part of the certificate, and the certificate is immutable.
There is one more permanent decision that does not appear in any table, because it is not a value you type. It is whether the certificate authority you are about to build is the first one this organisation has ever had. Very often it is not. Someone installed the role years ago, on a domain controller, to get a certificate for a single application, and then left. The objects are still in the directory, the old authority is still in the enterprise trust configuration, and clients are still being told to trust an issuer that no longer exists and whose revocation list expired in a previous decade. Building a clean hierarchy alongside that is how you get a validation failure that makes no sense against your new, correct configuration. Finding and clearing it is a prerequisite, not an optional tidy, and it is the first thing I check on any engagement before touching a build.
Where this series goes
Everything after this article builds one hierarchy and then operates it. The offline root comes first, designed around the fact that it is almost never running, and then built.
What comes second is the article I think matters most, and it comes second deliberately. Revocation is not a cryptographic problem, it is a distribution problem, and it is the only part of a certificate authority that has to be highly available. The signing service can be down for a week and nobody will notice until someone needs a new certificate. Let the revocation list become unreachable, or simply let it expire, and authentication fails across the estate for certificates that are perfectly valid. Two web servers, one name, and a publication design that removes the replication layer entirely is the answer I have settled on, and I will show why the obvious alternatives are worse. It sits ahead of the issuing authority in this series for a practical reason as well as a rhetorical one: the issuing authority inherits its distribution points from the root, and you cannot validate it until those URLs resolve. Build the distribution layer before the thing that depends on it.
The issuing authority follows, which is where Active Directory integration starts earning its keep, and where a default installation will happily begin issuing certificates the moment the service starts, whether you meant it to or not.
Certificate templates follow, which in 2026 is no longer a walkthrough of a settings dialog. It is the article where a reader learns their certificate authority is an attack surface, that Microsoft now ships assessments for a taxonomy of certificate authority misconfigurations in its own security tooling, and that one particular template setting quietly stopped working with domain authentication when strong certificate mapping enforcement completed. After that, the operational articles, because the maintenance calendar is the deliverable that keeps a PKI alive and almost nobody produces one.
The series ends where the on-premises estate meets the cloud, with the ceremony in which your own authority signs a certificate for an issuing authority that lives in Intune. It is four commands and about ten minutes, and it is completely unforgiving of one thing you will have already fixed by then, if you have followed the articles in order.
On-Prem PKI
Next: [P 2] The Offline Root: Designing for a Machine That Is Almost Never On ›
