Certificate Templates

What Certificate Templates Actually Are

When you're running a Windows PKI and need to issue certificates beyond the default ones, you work with certificate templates. That's it. No mystique. The template is a stored schema that tells the CA what kind of certificate to produce — key type, validity, extensions, who can enroll, whether the private key is exportable, whether auto-enrollment is allowed. You configure it once and every certificate issued under that template inherits those settings. I used to think you had to manually edit each certificate request. You don't. Template-driven issuance means the RA or certification authority reads the template and fills in the fields. The template is a container for policy, not a per-certificate config. Once you understand that distinction everything else follows naturally.

Working with Certificate Templates in Practice

The tool you touch is CertTemplate.msc on the CA server or a machine with AD CS tools installed. Open it, right-click, create new. You'll see two views — the old Certificate Templates console and the newer AD CS management console. Use whichever you have access to. Both let you create, publish, and delegate. Here's the part nobody puts in the documentation. A certificate template does not exist until it is published to Active Directory. If you create a template but don't publish it, nothing changes on the CA. The CA pulls its available templates from AD, not from your local edits. This tripped me up for weeks on a lab build where I kept wondering why the new template never showed up in the enrollment web page. It turned out I had clicked "Create" but skipped the publish step. After publishing it appeared within the replication interval. Check repadmin /showrepl if you're in a multi-domain setup and it still doesn't appear. The template you build controls these things:

• Certificate validity period — how long the issued cert lives. Set this carefully. I've seen a template with a 10-year validity because someone copied an old template without adjusting the field. The cert chain looked fine until revocation checking started failing across the org.
• Key usage and enhanced key usage — determines what the certificate is actually allowed to do. Server Authentication vs Client Authentication vs Code Signing. Pick wrong and the cert gets rejected by the relying party before you even notice.
• Subject Name — can be supplied by the requester, constructed from AD attributes, or fixed. AD attribute construction is the default and usually what you want. For computer certificates it pulls the machine name automatically.
• Renewal period — when the client should start the renewal process. Default is 60% of the validity period. Change it if you have specific compliance requirements.
• Key length and algorithm — RSA 2048 is the minimum most people accept now. ECDSA is cheaper on mobile devices and some IoT endpoints but check your compatibility list first.

Delegation is where most people mess up. Security tab on the template controls three things: who can enroll, who can read the template, and who can manage it. Enroll permission is the one that matters for end users. Read permission is needed for auto-enrollment to work because the client has to fetch the template. Manage permission is for admins who need to edit the template. I once saw a situation where auto-enrollment was failing because the computer accounts didn't have Read permission on the template — they had Enroll but not Read. The enrollment engine couldn't even look at the template definition. Added Read and it worked immediately. Here are the edge cases I've hit personally and how I worked around them. Pitfall 1: Copying templates without understanding the source. When you copy a template, you inherit every setting including the ones you didn't notice. I copied the "Computer" template for a custom internal CA and never realized the original had "Supplied Subject Name: DNS only" instead of "Supplied on request." Requests that included a full distinguished name got rejected silently. The fix was to explicitly set the Subject Name field on the copy rather than inheriting the parent. Now my new templates are never based on existing ones — I start from scratch or clone only when I've reviewed the original first.

Pitfall 2: Overlapping template eligibility. If two templates both allow a user to enroll and both produce certificates with the same EKU, the client picks one arbitrarily. This caused a real problem in my environment where workstation auto-enrollment was pulling the "User" template instead of the "Computer" template for machine certs. The resulting certificate had the wrong subject and failed group policy processing. The solution was to use template discrimination — set the template to only allow enrollment by computer accounts and disable user enrollment entirely. Then use the certificate template policy OIDs to make the intent explicit. Group Policy can enforce this if you publish the right extension. Pitfall 3: Revocation checking breaks after template migration. When you migrate from a legacy CA to a new one and reuse template IDs, the revocation lists can get confused if the template metadata doesn't match exactly. I encountered this when rebuilding a PKI on Windows Server 2022 after the 2016 server died unexpectedly. The new CA accepted the published templates but CRL distribution points referenced the old CA's DN. Certificates issued under those templates couldn't be validated. The workaround was to publish the templates, then use certutil -setreg to update the CRL and AIA paths on the new CA, then re-publish the templates. Takes about 15 minutes if you know the commands. Pitfall 4: Exportable key templates create a security hole. Marking a template as "Exportable Private Key" is convenient for disaster recovery but it means anyone who gets access to the certificate store can export the key. I've seen this cause real damage when a compromised workstation pulled an exportable client cert and the attacker used it to impersonate the machine. The fix is simple: don't make keys exportable unless you have a documented reason. Use the template to enforce this. Put "No Exportable Private Key" as the default and require admin override for the rare cases where you need it.

How Enrollment Actually Works

The client doesn't talk to the CA directly during auto-enrollment. It goes through the certificate request agent, which reads the published template from AD, builds a PKCS#10 or CER request, sends it to the CA, and installs the result. The agent checks template permissions before it even tries to request. If your template has the wrong ACL the request fails at the agent layer — you never see an error from the CA because the request never reaches it. The registry keys involved are under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Template. I use these when troubleshooting why a template isn't being picked up. Sometimes the issue is a stale cached template list in the registry. Clearing the cache with certutil -pulse forces a refresh. This usually resolves the problem within 5 minutes after a reboot. For manual enrollment you go to certlm.msc or certlm.msc on the local machine, right-click Personal, All Tasks, Request New Certificate. The wizard reads published templates from AD and shows you the available ones. If your template doesn't appear here, check the publish status and the enrollment permissions. Those are the two most common reasons.

Template Design Principles I Follow

My current approach to building templates is conservative. I never publish a template without a documented purpose. Every template gets a name that includes the purpose, the intended subject, and the validity period. Something like INT-WKS-AutoEnroll-365d instead of WorkstationCert. It takes longer to name them correctly but it saves hours later when you're auditing 40 templates and can't tell which one issues cross-certificates. I also avoid mixing concerns in a single template. One template for machine auth, one for user auth, one for code signing. Don't try to make one template handle all three because the key usage extensions will conflict and you'll spend more time debugging than designing. The template system is flexible enough to handle each case separately without much extra effort. If you're starting fresh and don't have existing templates, I'd recommend beginning with the default templates from Microsoft and customizing from there. Don't build from scratch unless you've used the defaults enough to understand what each field actually controls. The learning curve is steeper than it looks and the consequences of getting it wrong are real — misconfigured templates have caused certificate validation failures across entire domains that took days to untangle.