Certificate templates and enrollment

Separate three publication operations

An enterprise CA issues from certificate templates stored in AD’s Configuration partition. Creating a template, adding it to a CA’s issuance list and publishing an issued certificate into AD are three different changes. A standalone CA doesn’t use AD certificate templates. The template management guide covers each operation.

Record the template’s short name, display name, OID, version and revision. A command expecting the short name can fail when given a similar-looking display name. Record the exact issuing server\CA name as well: different enterprise CAs can issue different subsets of the same forest’s templates.

certutil -config "CA01\Contoso Issuing CA" -ping
certutil -config "CA01\Contoso Issuing CA" -catemplates
certutil -v -dstemplate WikiPilotTLS

These check the request interface, the CA’s template list and the named template. A ping can succeed while enrollment is denied or issuance fails. Save the output before editing anything. Certutil command reference.

Identify the actual requester

A computer request normally exercises computer-account permissions and machine certificate/key storage. A user enrollment exercises a different identity and store. A successful administrator test can therefore bypass the original failure.

Before reproducing, capture the requester, template, policy server, CA, request ID and HRESULT. Inspect client Application events from the certificate-enrollment providers and the CA’s failed/pending request record. Discover available provider/log names on that machine rather than assuming every version exposes identical channels:

Get-WinEvent -ListProvider '*CertificateServicesClient*' |
    Select-Object Name,LogLinks

Get-WinEvent -FilterHashtable @{
    LogName = 'Application'
    StartTime = (Get-Date).AddHours(-2)
} | Where-Object ProviderName -like '*CertificateServicesClient*' |
    Select-Object TimeCreated,Id,ProviderName,Message

If there’s no matching CA request record, start with policy discovery, template availability, client eligibility and enrollment transport. A denied request ID tells you the request reached the CA and gives you a server-side error to follow. A pending request also reached the CA; it isn’t a transport failure.

Check requester and CA permissions separately

The requester needs the appropriate template rights; autoenrollment additionally requires Autoenroll. CA-level enrollment access and template-level enrollment permission are separate checks. The MS-WCCE permission rule specifies 0x80094012, CERTSRV_E_TEMPLATE_DENIED, when template enrollment authorization fails.

The CA computer must also be able to read the template. Removing Authenticated Users can remove that access. 0x80094800, CERTSRV_E_UNSUPPORTED_CERT_TYPE, can result even when the template exists and an administrator can inspect it. Verify publication, replication and the CA’s Read permission before recreating the template. Microsoft documents this CA-cannot-read-template failure.

Check effective group membership, inherited deny entries and the exact issuing CA. Do not solve a narrow enrollment failure by granting broad groups Full Control or unrestricted enrollment.

Compare template identity and revision across replicas

Template schema version and template revision are different fields. revision is the major revision; msPKI-Template-Minor-Revision is the minor revision. Preserve the OID and both revisions from the client’s policy view and the CA’s view, alongside msPKI-Template-Schema-Version.

The client and CA need not retrieve policy from the same DC. A new permission or template change can reach one before the other. In the MS-WCCE template-version rules, a request requiring a higher revision than the server has can fail; a server with a newer revision uses its newer template. Repeatedly editing the template while its first change is still converging makes that comparison harder.

Supersedence doesn’t handle the whole renewal and cleanup job. A replacement template can trigger enrollment for a new certificate, but won’t automatically remove the old certificate from the user’s AD certificate store on current Windows. Microsoft’s supersedence KB explains this behavior. Check which certificate the application selects while both exist. Issuing the replacement hasn’t retired the old credential.

Review what the template authorizes

Before a pilot, review subject/SAN construction, application policies/EKUs, key usage, provider and algorithm, private-key exportability, approval requirements and enrollment-agent signatures. For authentication templates, requester-supplied names deserve particular scrutiny: the requester influences the identity placed in the certificate. Review who can modify the template and CA settings as well as who can enroll.

Use a narrowly scoped duplicated template for a disruptive change. Current template compatibility controls still use the available CA/recipient compatibility levels; the presence of Server 2025 in the estate does not imply a Server 2025 template dropdown exists. Validate the provider against the actual requester and consuming application. A certificate the CA can issue might still be unusable by an older client or an HSM-backed workload.

Reproduce issuance deliberately

With an approved pilot template published and permissions established, this requests and installs a machine certificate on the test requester:

certreq -enroll -machine WikiPilotTLS

Use a template designed for this test; the command can generate keys and create CA/database records. For a user test, use the correct user context rather than treating the machine switch as interchangeable. Capture any request ID and disposition. The Certreq reference describes enrollment, retrieval and acceptance as separate operations.

Check the issued certificate’s subject and SAN, EKUs, provider/key association, validity and template identity. Then try the application. Enrollment can succeed while the application selects another certificate or can’t use the private key.

Diagnose renewal separately from first enrollment

An issued certificate’s lifetime is constrained by CA policy, template validity and the signing CA certificate’s remaining validity. Extending only the template cannot make the CA issue past its own certificate’s expiry. Certificate validity constraints.

Autoenrollment renewal also depends on the renewal window. Microsoft’s documented normal behavior requires the certificate to have completed 80% of its lifetime and be within that window. Unsupported validity/renewal combinations can cause a new enrollment instead of renewal, unexpectedly invoking manager approval. Inspect pKIExpirationPeriod and pKIOverlapPeriod rather than repeatedly approving symptoms. Renewal-window troubleshooting.

certutil -pulse triggers autoenrollment processing and can issue or renew certificates; record existing state first. It does not make a machine eligible for an unpublished template or correct an ACL. Test renewal, application certificate selection and key access after policy changes. When retiring a template, remove future issuance deliberately and account for certificates already issued: removing the template from a CA does not revoke those certificates.

Separate enrollment policy from request submission

With web-based enrollment, CEP supplies enrollment policy and CES submits requests over HTTPS. A client can discover policy successfully while request submission still fails. Inspect each endpoint’s TLS identity, authentication mode, service identity, directory/CA connectivity and delegation requirements separately. CEP overview, CES guidance.

Key-based renewal is another distinct path: a valid existing certificate authenticates renewal, and a renewal-only configuration does not accept ordinary new requests. A successful first enrollment therefore does not prove off-network renewal. Test the authentication mode and network location used when the client later renews.

Continue with CEP/CES troubleshooting for policy-cache evidence, advertised enrollment endpoints, the service-to-CA hop, application failover and relay protection.