By the end of this article your authority issues certificates: five templates cloned and scoped, machines and domain controllers enrolling automatically, and a controlled manual path for the certificates that cannot be automated. This is where the hierarchy starts doing work.
The authority currently has no templates published at all, which is where [P 4.1] deliberately left it. Everything below is a grant being made on purpose.
Prerequisites. The issuing authority from [P 4.1], running and validating clean. Domain Administrator rights, and rights to create a security group. The certificate templates console, available from the certification authority console or as a standalone snap-in on a machine with the remote administration tools. A test workstation you can force a policy refresh on.
The convention. Templates carry an organisation prefix and a role, with no spaces in the internal name: CSJComputerAuthentication, CSJUserAuthentication, CSJDomainController, CSJWebServer and CSJWebServerShared. The prefix makes it obvious in any certificate dump which templates are yours and which shipped in the box, which matters the first time you audit an estate you did not build.
Step 1. Create the enrolment group first
New-ADGroup -Name "GRP-PKI-WebServer-Enroll" -GroupScope Global -GroupCategory Security `
-Path "OU=Groups,DC=catsnackjack,DC=com" `
-Description "Members may enrol CSJWebServer certificates. Add computer accounts, not users."
New-ADGroup -Name "GRP-PKI-WebServerShared-Enroll" -GroupScope Global -GroupCategory Security `
-Path "OU=Groups,DC=catsnackjack,DC=com" `
-Description "Members may enrol CSJWebServerShared certificates, whose private keys are exportable."Create it before the template, so the template’s permissions can be set once rather than revisited. The two templates in this set that are not scoped to a broad built-in group are the web server pair, and that is precisely because they are the ones where the requester names the subject. They get separate groups because they are not the same grant, as step 5 explains.
Step 2. CSJComputerAuthentication
Duplicate Workstation Authentication. This is the workhorse: machine identity for network authentication, VPN, and device identity generally.
| Setting | Value | Why |
|---|---|---|
| Compatibility, authority | Windows Server 2016 | The current ceiling in the template editor. Determines the schema version, which is fixed once saved. |
| Compatibility, recipient | Windows 10 / Server 2016 | Set no higher than your oldest client. Too high and clients never see the template, which presents as automatic enrolment doing nothing. |
| Template display name | CSJComputerAuthentication | The internal name is derived from this and cannot contain spaces or be changed afterwards. Verify it before saving. |
| Validity period | 1 year | Within the authority’s one-year ceiling. Short enough that a compromised key has a bounded life. |
| Renewal period | 6 weeks | Comfortably more than a few hours and comfortably under a fifth of validity. Too large and clients re-enrol instead of renewing. |
| Publish certificate in Active Directory | Checked | Makes the issued certificate discoverable on the computer object. |
| Provider category | Key Storage Provider | The modern provider family. Required for anything that will later want post-quantum or hardware-backed keys. |
| Algorithm and minimum key size | RSA 2048 | End-entity keys do not need to match the authority’s 4096. 2048 is current guidance and is materially faster on constrained devices. |
| Request hash | SHA256 | Matches the hierarchy. |
| Subject name | Build from Active Directory (inherited) | Do not change this. It is what produces the security identifier extension that domain authentication now requires. |
| Security: Domain Computers | Read, Enroll, Autoenroll | Autoenroll is a separate right from Enroll. Granting only the first two is the most common reason automatic enrolment silently does nothing. |
| Security: SUBCA computer account | Read | The authority reads templates as itself. Removing broad read access without granting this produces an unsupported certificate type error that looks nothing like a permissions problem. |
To add a computer account in the security tab you must open Object Types and enable Computers first; computer accounts are not returned by the default search, and the usual reaction to not finding one is to grant something broader instead.
Step 3. CSJUserAuthentication
Duplicate User. Same compatibility, validity, renewal, provider and hash as the machine template, scoped to Domain Users with read, enrol and automatic enrolment, plus read for the authority’s computer account.
One deliberate change: set the purpose to signature rather than the default signature and encryption. The built-in User template includes the encrypting file system, and encryption certificates raise a question the rest of this build does not answer, which is what happens to encrypted data when a user’s key is lost. That is a key archival and recovery design, it is genuinely involved, and issuing encryption certificates without one is how organisations discover the problem at the worst moment. If you later need file encryption, design the recovery model first and publish a separate template for it.
That change alone is not sufficient, and this is the step people stop one move short on. Purpose lives on the request handling tab and governs key usage. The application policies, which are what the certificate actually advertises it may be used for, live on the extensions tab and are untouched by it. A duplicate of the User template therefore still lists encrypting file system and secure email alongside client authentication, even with the purpose reduced. Edit the application policies and reduce them to client authentication only. A template whose stated purposes exceed its intended use is precisely the standing grant this series has been arguing against, and leaving two of them in place while writing a paragraph about removing one is not a defensible position.
If nobody in your estate actually uses user certificates, do not publish this template at all. An unused published template is a standing grant with no compensating benefit.
Step 4. CSJDomainController
Duplicate Kerberos Authentication, not the older Domain Controller or Domain Controller Authentication templates. The Kerberos Authentication base carries the key distribution centre authentication purpose, which is what modern smart card logon and Windows Hello for Business depend on, and it is the current recommendation. Cloning the older template produces certificates that work for secure LDAP and fail for authentication scenarios you have not built yet.
There is one step here that this build does not need and almost every other estate does. On the new template’s superseded templates tab, add Domain Controller, Domain Controller Authentication and Kerberos Authentication, which tells automatic enrolment to replace whatever the domain controllers are currently holding rather than issuing alongside it. In this build it is unnecessary, because LoadDefaultTemplates = 0 means this authority has never published those templates and there is nothing on it to supersede. But a domain controller that received a certificate from a previous authority will keep using it indefinitely, and superseding is the mechanism that displaces it. If this hierarchy is replacing anything, do this. If it is genuinely the first, skip it and remember it exists.
Settings match the machine template, with enrolment granted to Domain Controllers and Enterprise Domain Controllers, both with automatic enrolment, plus read for the authority’s computer account.
Expect a visible effect from this one. Once published and once the policy in step 6 applies, every domain controller enrols on its next refresh without anyone asking it to. Seeing domain controller certificates appear in the issued list shortly afterwards is correct behaviour and not a misconfiguration.
Step 5. The web server pair, and why it is a pair
Duplicate Web Server, twice. This is the template where the requester supplies the subject, which is unavoidable and which is why every other setting on it is tightened. It is also the only certificate in this set that routinely has to exist in more than one place, and those two facts pull in different directions, which is the reason for two templates rather than one.
An earlier version of this build sheet had a single web server template with an exportable key and a lowered compatibility ceiling, on the reasoning that some certificates get carried to load balancers and appliances. That is true of some of them. Applying it to all of them means the internal site that will never export anything is issued from the legacy provider family and holds a key that can be copied off the machine, for the convenience of a minority. That is the opposite of the argument this build makes everywhere else.
CSJWebServer, the default
The one you should reach for unless you know otherwise. One host, one key, generated on that host and never leaving it. Internal sites, management interfaces, internal APIs, secure LDAP on anything that is not a domain controller.
| Setting | Value | Why |
|---|---|---|
| Subject name | Supply in the request | Unavoidable. A web server certificate carries names that exist in no directory object: aliases, load balancer names, and multiple hostnames on one certificate. |
| Purpose | Server Authentication only | The control that makes the setting above safe. Do not add client authentication, smart card logon or any purpose that authenticates a principal. That combination is the escalation path. |
| Enrolment | GRP-PKI-WebServer-Enroll only, Read and Enroll | No automatic enrolment, and no broad group. A named population that somebody has to be added to. |
| Autoenroll | Not granted to anyone | There is nothing for Windows automatic enrolment to supply. A service answers to several names, typically web, web1, web2 and a load balancer alias, and those exist only in the head of whoever is building it. No unattended directory-driven process can produce that request, so a person makes it, every time. |
| Private key | Not exportable | The default, and the change from the previous version of this build. A key that cannot leave the machine is one fewer thing to lose control of, and a single-host certificate has no reason to travel. |
| Compatibility, recipient | Windows 10 / Server 2016 | Matches the other templates. Nothing here is being exported, so nothing needs the legacy provider family. |
| Provider category | Key Storage Provider | As everywhere else in this build. |
| Validity | 1 year | Matches the authority ceiling. |
CSJWebServerShared, for certificates that have to travel
Named for the situation rather than the setting, deliberately. A reader choosing between CSJWebServer and CSJWebServerExportable is choosing a checkbox. A reader choosing between it and CSJWebServerShared is answering a question about their architecture, which is the question you want asked.
| Setting | Value | Why |
|---|---|---|
| Everything above | Identical | Same subject handling, same single purpose, same validity. Only the two rows below differ. |
| Private key | Allow export | The whole reason this template exists. A load balancer terminating the connection, a cluster sharing a name, an appliance that wants a PKCS#12 file, a Linux host. It is a real trade: an exportable key can be copied off the machine by anyone with sufficient rights, permanently. |
| Enrolment | GRP-PKI-WebServerShared-Enroll only, plus manager approval | Smaller than the other group, and worth the approval step here even though it is optional on the default template. A request against this template is a deliberate act and should look like one in the authority’s records. |
| Compatibility, recipient | Lower if a consumer requires it | Lower the ceiling only when something downstream genuinely needs the legacy provider family. Start at the same level as everything else and drop it if an appliance refuses the result, rather than dropping it in advance. |
That row is not hedged because the answer was unclear. Exportability and provider family are independent: a Key Storage Provider carries an export policy like any other key property, and nothing in the platform ties a copyable key to the legacy family. The only thing that should ever drive the ceiling down is a consumer that cannot handle CNG at all, which is a fact about that appliance rather than about this template. The exported file is a standard PKCS#12 and the format does not carry the provider that generated the key, so the usual argument for lowering the ceiling is weaker than it is usually stated. Test with the modern setting first. If your load balancer takes the file, you never needed to lower anything.
The operational payoff of the split is the part worth keeping. With one template you cannot tell from the authority’s records whether a certificate went to something that needed a copyable key or to something that did not. With two, that question is answered by which template was used, and by a membership list somebody has to be added to.
Three things people conflate
A key marked exportable at enrolment can be copied off the machine by anyone with sufficient local rights, for as long as it exists, and nothing later revokes that ability. A key archived by the certificate authority is stored encrypted at the authority so it can be recovered if the holder loses it, which is a different mechanism with a different threat model, applies to encryption rather than signing, and requires a key recovery agent design this build deliberately does not have. A key that is neither can only be replaced, not recovered. Allow export is not how you get key recovery, and treating it as though it were is how organisations end up with copyable keys everywhere and still no way to recover anything.
Certificates from both templates carry no security identifier extension, because the authority never looked anything up. That is correct and harmless here, because nothing authenticates a user with a web server certificate. It would be fatal on a template used for logon, which is the whole argument of the doctrine article.
One boundary, stated once so nobody has to infer it. Certificates from either of these templates are private PKI certificates. The CA/Browser Forum limits on publicly trusted TLS certificates do not apply to them, and neither does the shortening schedule that is currently taking public certificate lifetimes down toward 47 days. Nor do these templates work for a public website, because an unmanaged internet client has never heard of your root and never will. Public services need a publicly trusted certificate authority and an automated renewal path, and that is a different lifecycle that this series does not cover.
Step 6. Publish, and only these
In the certification authority console, under Certificate Templates, choose New and Certificate Template to Issue, and add the five. Nothing else.
certutil -CATemplatesExpected result: exactly five templates listed. If anything else appears, the authority was not built with default templates suppressed, and you should remove the extras rather than leave them. Every line in that output is a standing grant.
Step 7. Turn on automatic enrolment
Create or edit a group policy object linked where you want certificates to appear. Configure the Certificate Services Client automatic enrolment setting under both computer and user configuration, in the public key policies, and enable both options: renew expired certificates and update certificates that use certificate templates. Enabling the policy without those two options produces enrolment that never renews, which is a problem you meet a year later.
# on a test client
gpupdate /force
certutil -pulse
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, NotAfter, IssuerExpected result: a certificate issued by CatSnackJack Issuing CA appears in the machine store. If nothing happens, work the three conditions in order: is the template published to the authority, does the target principal hold the separate automatic enrolment right, and is the compatibility level at or below the client’s version. Those three account for almost every case.
The end-to-end test
This is the test the whole series has been building toward, and it exercises every article before this one in a single certificate.
$c = Get-ChildItem Cert:\LocalMachine\My |
Where-Object { $_.Issuer -like "*CatSnackJack Issuing CA*" } | Select-Object -First 1
certutil -dump -v $c.PSPath
certutil -verify -urlfetch (Export-Certificate -Cert $c -FilePath C:\temp\test.cer).FullNameIn the dump, confirm five things. The subject is the machine’s own name, built by the authority and not asserted by the client. The template name is CSJComputerAuthentication. The validity is one year. There is an extension carrying the object identifier ending 311.25.2, which is the security identifier that makes this certificate strongly mapped and therefore usable for domain authentication. And the distribution point and authority access extensions read http://pki.catsnackjack.com/pki/ rather than a directory path or a hostname.
Then the verification with fetching enabled should build the full chain to the root, retrieve both revocation lists over HTTP, and report no errors. That single command proves the root build, the distribution web servers, the DNS name, the signing ceremony, the publication configuration and the template, all at once. If it passes, the PKI is correct.
A worked example: a certificate for a load-balanced service
A service is reached at intranet.catsnackjack.com, runs on two servers named web01 and web02, and sits behind a load balancer. It needs one certificate carrying all three names, installed on both servers.
Add the computer account of web01 to GRP-PKI-WebServerShared-Enroll, and restart it so the new group membership is in its token. This is the shared template rather than the default one, because the certificate has to exist on more than one machine, and that is the only thing the pair differs on. On web01, open the local computer certificate store, request a new certificate, select CSJWebServerShared, and because the template supplies its subject in the request the wizard will ask for details. Set the common name to intranet.catsnackjack.com and add all three names as DNS entries under alternative name. Enrol.
The request will not issue immediately. CSJWebServerShared requires manager approval, which is the deliberate friction on the template that produces copyable keys, so the request sits pending until somebody with the authority to approve it does so on the authority. Approve it, then retrieve the issued certificate on web01.
Export the result with its private key to a password-protected file, import it on web02 and on the load balancer if it terminates the connection, then bind it. One certificate, three names, two servers, and one enrolment event you can point at in the authority’s issued list with a named person attached to it.
Note what the restriction bought. Obtaining that certificate required somebody to add a computer account to a group deliberately. Without that step the request is refused, which is the difference between a template that names its own subject safely and one that does not.
Rollback
Unpublishing a template from the authority stops it being requestable immediately and affects nothing already issued. That is the fastest containment action available if a template turns out to be wrong, and it is worth knowing before you need it.
# remove a published template from the authority
certutil -SetCATemplates -CSJWebServer
certutil -SetCATemplates -CSJWebServerShared
certutil -CATemplatesDeleting the template object from the directory is a separate and more serious act, because anything referencing it, including a supersede list on another template, breaks. Unpublish first, confirm nothing is affected, and only then consider deletion. Certificates already issued from a template remain valid whatever you do to the template; if you need them gone, revoke them.
Completion checklist
Five templates exist with the organisation prefix and no spaces in their internal names. Exactly five are published on the authority and nothing else. The two web server templates differ in exactly one intended respect, key exportability, and carry separate enrolment groups. Machine, user and domain controller templates build their subjects from the directory. Both web server templates supply their subject in the request, carry a server authentication purpose only, are scoped to a named group and grant automatic enrolment to nobody. They differ in exactly one respect: CSJWebServer does not permit key export and CSJWebServerShared does, which is why the second one is scoped more narrowly and requires manager approval. Every template grants read to the authority’s computer account. The automatic enrolment policy is applied with both renewal options enabled. A test machine has enrolled without intervention. Its certificate carries the security identifier extension, names the expected template, and validates from outside the domain with revocation retrieved over HTTP. Domain controllers have enrolled on their own.
The PKI is now doing its job. What remains is keeping it alive, which is the next article and is the part that determines whether any of this is still working in five years.
On-Prem PKI
‹ Previous: [P 5] Templates and the Discipline of Issuance
Next: [P 6] Operating a PKI: Trust, Backup, and the Calendar ›
