The root is ceremonial. The issuing authority is the machine that actually signs things, holds a live key, sits in your domain, and is the only part of this hierarchy an attacker has any interest in at all.
Everything about it is a trade. Joining it to Active Directory is what makes a private PKI usable at all, because it is what lets certificates be requested automatically, by the right principals, with subjects the directory fills in rather than the requester asserting. It is also what puts the authority inside the blast radius of the directory, gives it an object with an access control list that most people never look at, and makes it reachable by every machine in the estate. You do not get one without the other, and pretending otherwise is how certificate authorities end up as the quiet route to domain compromise.
What enterprise integration actually buys
Three things, and they are worth separating because people tend to name only the first.
The first is certificate templates. A template is a definition of a kind of certificate, stored in the directory, describing what it is for, how long it lasts, how the subject is constructed, what key material is acceptable, and who may ask for one. Without templates every request is a bespoke negotiation. With them, the authority becomes a policy engine rather than a signing service.
The second is automatic enrolment. Machines and users obtain the certificates they are entitled to without anyone requesting anything, and renew them without anyone remembering. This is the feature that makes certificate-based authentication survivable at scale, and it is the difference between a PKI that gets adopted and one that gets abandoned after the first renewal cycle.
The third is the one that has become load-bearing for reasons nobody anticipated when it was designed. An enterprise authority builds the subject of a certificate from the directory object of whoever requested it, rather than from what the requester claimed. That means the certificate says who the directory says they are. It also means the authority can embed the requester’s security identifier as an extension, and since strong certificate mapping enforcement completed, that extension is what allows a certificate to be used for domain authentication at all. An authority that cannot see the directory cannot do this, which is why the question of enterprise versus standalone is no longer really a question for an issuing authority.
The directory is not a convenience here. It is the source of the identity assertion the certificate exists to carry.
The signing ceremony is the moment the hierarchy exists
Installing the role on the issuing authority does not produce a working authority. It produces a request. The service will not start, and cannot start, until a certificate signed by the root is installed. Somebody carries that request to a machine with no network, has it signed, and carries the answer back.
It is tempting to treat this as an inconvenient file copy. It is the single event that creates the hierarchy, and it is worth treating with a little ceremony because everything it decides is fixed at that instant. The lifetime of the issuing authority’s certificate is set by the root, not by the subordinate, no matter what the subordinate’s own policy file says. The distribution points written into that certificate are the root’s, and they are the URLs every relying party will use to check whether this authority has been disowned. If those are wrong, they are wrong for the life of the certificate and the only remedy is a new request and a new signature.
This is also the point where the offline root earns everything it costs. You get to hold, in one room, the only two objects that matter: a request that asserts nothing yet, and the key that will make it true. Doing that deliberately, with the values checked against a document rather than remembered, is the difference between a hierarchy you can defend in an audit and one you built on a Thursday.
A default installation can issue certificates immediately
Here is the behaviour that surprises people, and it deserves to be stated bluntly. When an enterprise issuing authority is installed with defaults, a set of certificate templates is published to it as part of installation. Publishing a template to an authority is what makes it requestable. Several of the default templates permit enrolment by ordinary authenticated principals. So from the moment the service starts, before anyone has configured anything, a domain user can obtain certificates from your brand new authority.
Whether that is dangerous depends entirely on what those templates allow, and that is the subject of the next article rather than this one. What matters here is the shape of the decision. You can install with defaults and remove what you do not want, which is how most guides do it, including one I wrote. Or you can install with nothing published and add only what you intend, which takes the same amount of work and never has a window in which the authority is issuing things you have not thought about.
I have come round firmly to the second. The policy file directive that suppresses default templates costs one line, and the mental model it produces is the right one: publishing a template is granting a capability, and an authority should hold exactly the capabilities you have deliberately given it. Starting from empty makes that explicit. Starting from the defaults makes it an exercise in remembering what to take away, and the thing about removal exercises is that they are only as good as the list you were working from.
Validity is the shortest of several answers
The lifetime of a certificate this authority issues is not the number in the template. It is the shortest of four things: the template’s validity, a registry ceiling on the authority, the remaining life of the authority’s own certificate, and in some configurations a value supplied in the request. Three of those are easy to reason about. The third is the one that produces confused support tickets years later.
An authority cannot issue a certificate that outlives its own. So an issuing authority with a five-year certificate, handing out certificates with a one-year life, behaves exactly as expected for four years. In year four and a half it begins issuing certificates that expire in six months, because that is all the life it has left to give. Nothing is broken, no setting has changed, and the estate quietly starts renewing twice as often. In the last weeks it issues certificates measured in days.
This is why the convention is to renew a certificate authority at half its life rather than near the end of it. It is not superstition about round numbers. It is the point at which the authority still has enough remaining validity to issue a full-length certificate, and renewing then means nothing downstream ever notices. Put the date in the same calendar as the root’s annual appointment, because these two dates are the entire long-term maintenance schedule of a private PKI and everything else is reactive.
Auditing, role separation, and the cost of both
Auditing on a certificate authority takes two switches and produces nothing with only one. There is a filter on the authority describing which categories of event to record, and there is an operating system audit policy that must permit certification services events to be written at all. Enable the first alone, which is what most build guides show, and you have an authority that reports itself as fully audited and writes no events. It is worth verifying by causing an event and looking for it, rather than by reading the configuration back.
Role separation is a stronger control and a genuinely double-edged one. It enforces that a single account cannot hold two administrative roles on the authority, so the person who manages the authority cannot also approve certificate requests. That is a real segregation of duties and in a regulated environment it may be required. What is less advertised is that once enabled, an account holding two roles is denied all operations, which includes the account that enabled it. Recovery requires a local administrator to disable the setting, and if the estate has been diligent about removing local administrator access, that can be an awkward afternoon. It also blocks local administrators from backing up the authority or configuring auditing, so those permissions have to be delegated explicitly to separate accounts. Enable it if you need it, and rehearse the recovery before you do.
The web enrolment question
Windows ships a web enrolment component that puts a request form on the authority, and it is genuinely useful for the handful of certificates that cannot be enrolled automatically, typically web server certificates for machines that are not domain members. It is also an HTTP endpoint on your certificate authority that accepts Windows authentication, and that combination is one of the better documented paths from an ordinary foothold to a certificate that authenticates as somebody else. Microsoft’s own security tooling now assesses for it by name. And the convenience is smaller than it looks, because those same requests can be submitted with certreq from an administrative workstation without standing up an endpoint at all, which is why the build sheet does not install it.
The mitigations are known and unglamorous: require HTTPS on that site, enable extended protection for authentication so a captured authentication attempt cannot be replayed elsewhere, and restrict who can reach it. My position is that you should install it only if you have a named use for it, and if you do, harden it in the same session rather than adding it to a list. An unused web enrolment site on an issuing authority is pure exposure with no compensating benefit, and it is installed by default in a great many builds simply because it was on the same page of the wizard.
What emerges from all of this is that the issuing authority is the only component in the hierarchy where the interesting decisions are about restraint. The root’s decisions are about permanence, the distribution layer’s are about availability, and this machine’s are almost entirely about what not to grant: which templates exist on it, who may ask, who may approve, and which endpoints are reachable. The build sheet that follows makes the machine, and it deliberately leaves it able to issue nothing at all, because that is the correct state for an authority whose templates have not been designed yet.
On-Prem PKI
‹ Previous: [P 3.1] Build Sheet: Redundant CRL and AIA Web Servers
Next: [P 4.1] Build Sheet: The Issuing CA, End to End ›
