A certificate template is not a form somebody fills in. It is a standing grant, published to an authority, that says a named set of principals may obtain a certificate of this shape, on demand, without anyone approving it. Read that sentence again with your own template list in mind.
For most of the history of Active Directory Certificate Services, templates were treated as a configuration chore. You duplicated something, adjusted a validity period, ticked a box for automatic enrolment and moved on. That era ended somewhere around 2021, when the security research community published a taxonomy of certificate authority misconfigurations and demonstrated that a certificate template is one of the shortest paths from an ordinary domain account to domain administrator that exists in a default Windows environment. Microsoft now ships assessments for several of those misconfigurations in its own security tooling, which is about as clear a signal as the industry gets.
So this article is not a walkthrough of a settings dialog. It is about a small number of decisions that determine whether your certificate authority is infrastructure or a liability.
Clone, never modify, and why that is not a style preference
The templates that ship with a forest cannot be meaningfully edited. The oldest generation is read-only apart from its access control list, so there is no version of “just adjust the built-in one” that works. Duplication is the only path to a configurable template, and it has a second benefit that matters more in practice: the built-in template remains untouched, which means anything already relying on it keeps working, and your changes are visibly yours.
When you duplicate, the first thing you choose is a compatibility level, and it is worth understanding what that control actually is. It is not a preference. It determines the schema version of the resulting template, and the schema version cannot be changed once the template is saved. Set compatibility higher than your clients support and they will not see the template at all, which presents as automatic enrolment silently doing nothing. Set it too low and you lose capabilities you wanted. Microsoft’s own documentation is inconsistent here, describing three template versions in the certificate services pages while the protocol specification documents four, so treat the compatibility dropdown as the authoritative control and the version number as a consequence of it.
The internal template name, as opposed to its display name, is likewise fixed at creation and cannot contain spaces. It is the identifier that appears in certificates and in every diagnostic you will ever run. Getting it right is thirty seconds of attention that saves an afternoon three years later when you are trying to work out which of five similarly named templates issued a particular certificate.
Who decides what the certificate says
Everything interesting about a template comes down to one question: when a certificate is issued, who decides whose name is on it.
In the default and correct arrangement, the authority decides. It looks up the directory object of whoever made the request and builds the subject from what it finds. The requester cannot influence it. A machine asking for a certificate gets a certificate that says it is that machine, because the directory says so and the authority believes the directory rather than the requester.
The alternative is that the requester supplies the subject. This exists because some certificates cannot work any other way, and web server certificates are the case that proves it. A service is rarely reached by one name. It is reached as web, and as web1 and web2 behind it, and as whatever alias the load balancer answers to, and quite often as a name in a different DNS suffix entirely. All of those go on one certificate, in the subject alternative name, and none of them exists on the computer object of the machine that will hold it. There is nothing for the authority to look up.
That has a second consequence people sometimes miss. These certificates are not merely conventionally requested by hand; there is nothing for Windows automatic enrolment to automate. That mechanism builds a request from what the directory already knows, and the directory has no way to know that this month’s new service also answers to two aliases and a load balancer name. The names come out of the head of whoever is building the service, which means a person makes the request, every time, deliberately. Supply-in-request is therefore the correct and only answer for that class of certificate, and any advice that tells you never to use it has not thought about web servers.
Be careful how far that reasoning travels, though, because it is about one mechanism rather than about automation in general. Windows automatic enrolment cannot infer a service’s names. Other things can: a deployment pipeline knows what it is deploying, a certificate management platform holds an inventory, a script that builds the server can build the request in the same breath. Those paths exist and they matter more the shorter certificate lifetimes get. What they do not do is change the answer here, because a private certificate on a one-year life renewed by a person is a perfectly sustainable arrangement, and the same sentence stops being true the moment the certificate comes from a public authority on a lifetime measured in weeks.
Supply-in-request is not dangerous. Supply-in-request combined with an authentication purpose, available to everybody, is catastrophic.
That combination is the important thing to be able to recognise, because it is the single most consequential misconfiguration in the entire product. If a template lets the requester name the subject, and the certificate’s purpose includes something that authenticates a principal, and enrolment is available to ordinary users, then any domain user can request a certificate asserting that they are somebody else and then authenticate as that person. There is no exploit involved. The authority is working exactly as configured. The configuration is simply a standing offer to impersonate anyone.
So the test to apply to every template you publish is a conjunction, not a single setting. Does the requester name the subject? Does the certificate authenticate anybody? Who can enrol? A web server template with supply-in-request, a server authentication purpose, and enrolment restricted to a named group of server owners fails none of those and is entirely correct. The same template with client authentication added and Domain Users able to enrol is the worst object in your directory.
The setting that quietly stopped working
There is a second consequence of that same choice, and it caught a great many estates between 2022 and 2025 without them understanding why.
When an enterprise authority builds the subject from the directory, it also embeds an extension carrying the requester’s security identifier. That extension is what allows a domain controller to bind a certificate to an account with certainty, rather than inferring the link from a name that could match more than one thing. Microsoft calls that a strong mapping, and following a long and much-extended enforcement timeline, weak mappings are no longer accepted for authentication. The compatibility mode that let administrators defer this is gone, and the registry value that controlled it is no longer supported.
Here is the part that connects to the previous section. The authority only derives that extension when it is deriving the subject. If the template lets the requester supply the subject, the authority does not look anything up, and the extension is present only if the requester put it there. Certificates from supply-in-request templates are therefore weakly mapped by construction.
For a web server certificate that is entirely irrelevant, because nothing is authenticating a user with it. For anything intended to authenticate a person or a machine to a domain controller, it is fatal, and it fails at authentication time rather than at issuance, which makes it a confusing thing to diagnose. There are ways to make such a certificate work, by populating a strong mapping on the account by hand or by having the requester supply the identifier itself, which is what mobile device management platforms now do. But the clean answer is the structural one: certificates that authenticate should have their subjects built by the authority, and if you find yourself needing an exception, treat that as a design question rather than a configuration one.
Publishing is granting
A template can exist in the directory and be entirely inert. It becomes live when it is published to an authority, and Microsoft’s own remediation guidance for the misconfiguration described above includes, as one of its options, simply unpublishing the template, on the plain grounds that a template which is not published cannot be requested.
That is the highest-leverage control available and it is almost free. It also suggests the right default posture, which is the one this series takes: build the authority with nothing published, and add each template as a deliberate act. The alternative, installing with the default set and removing what you do not want, reaches the same place if you are thorough, and depends entirely on the completeness of the list you were working from. One of those approaches fails safe.
A defensible published set for an ordinary enterprise is smaller than most people expect. Something for machine authentication, something for user authentication if you actually use it, something for domain controllers, and something for web servers. That is four, and it covers the overwhelming majority of what a private PKI is asked to do. Everything else that ships in the box, the encrypting file system templates, code signing, enrolment agent, the various recovery agents, stays unpublished until somebody arrives with a named requirement, and then gets published deliberately with its enrolment scoped to whoever raised it.
One trap worth knowing before you start tightening access control lists. Stripping authenticated users from a template’s permissions feels like good hygiene and breaks issuance, because the authority itself reads the template through its own computer account. The symptom is an unsupported certificate type error that appears to have nothing to do with permissions. Grant each authority’s computer account read access on every template you publish and the problem never occurs.
The taxonomy, scoped honestly
The community research into certificate authority abuse produced a numbered catalogue of escalation paths, and you will see references to the whole range of them as though it were a standard. It is worth being precise about what is actually assessed by Microsoft’s tooling, because that determines what you will see rather than what exists.
Defender for Identity ships assessments for the template-level issues, being the supply-in-request case, templates with an any-purpose or absent purpose, enrolment agent templates, and two separate assessments covering template access control lists and template ownership. It also assesses authority-level issues: the flag that lets a requester inject a subject alternative name regardless of the template, dangerous permissions on the authority itself, the web enrolment endpoint accepting unprotected authentication, an unencrypted request interface, and an application policy injection issue. Several of the others in the published research have no Microsoft assessment at all.
The practical caveat matters more than the list. The authority-level assessments require a sensor deployed on the certificate authority itself, so an organisation with Defender for Identity but no sensor on that machine sees the template findings and none of the rest, and may reasonably conclude its authority is clean. If you are relying on this tooling as your assurance, check where the sensors are before you trust the absence of findings.
Automatic enrolment, and why it usually does nothing
Automatic enrolment is what makes a PKI survivable, because it removes both the request and the renewal from human hands. It requires three things to be true at once, and the failure mode when any one of them is missing is silence rather than an error.
The template must grant the target principals read, enrol and the separate automatic enrolment permission, which is a distinct right that people routinely forget while granting the first two. The policy setting must be enabled for the right context, machine or user, and configured to renew expiring certificates rather than merely to enrol new ones. And the template must actually be published to an authority. Miss the third and everything looks correct in the template editor while nothing happens anywhere.
The renewal window deserves a moment, because it is governed by a different convention from the one that applies to authorities. Certificate authorities are renewed at half their life. End-entity certificates renew in the last portion of theirs, and the renewal period on the template should be comfortably more than a few hours and comfortably less than a fifth of the validity. Set it too large and clients re-enrol rather than renew, generating new keys constantly and filling the authority’s database with certificates nobody asked for.
All of which is to say that the template list is the actual security posture of a certificate authority. The key length, the offline root and the hardware module are the things that get discussed, and none of them matters if a template lets somebody name themselves. The build sheet that follows publishes five templates and nothing else, and each of them is a deliberate grant with a named population attached.
On-Prem PKI
‹ Previous: [P 4.1] Build Sheet: The Issuing CA, End to End
Next: [P 5.1] Build Sheet: The Template Set, Autoenrollment, and Manual Enrollment ›
