AD CS Says “Certificate Template Not Supported”

A certificate template can exist in Active Directory, be published on the CA, have the correct OID and still fail enrollment.

In this case, the affected servers had enrolled successfully before, which made the failure more confusing. As their certificates approached renewal, both automatic enrollment and manual re-enrollment started failing, despite the template appearing to be configured correctly.

The Symptoms

Member Server Logs

Event ID 6

(0x80094800)

Automatic certificate enrollment for local system failed (0x80094800) 

The requested certificate template is not supported by this CA.

Event ID 13

0x80094800
CERTSRV_E_UNSUPPORTED_CERT_TYPE

The requested certificate template is not supported by this CA.

CA Sever Logs:

Oops, and this is why WEC\WEF is being implemented.

The CA logged a more useful warning:

Event ID 77
The ToyoMemberServerIPSec Certificate Template could not be loaded.

Element not found.

0x80070490 WIN32: ERROR_NOT_FOUND

Event ID 53

Certificate enrollment for Local system failed to enroll for a
ToyoMemberServerIPSec certificate...

The requested certificate template is not supported by this CA.

0x80094800
CERTSRV_E_UNSUPPORTED_CERT_TYPE

These would normally sends you straight to the CA console to check whether the template has been issued.

Which I did, and it was.

In this case, the CA could see the request but could not load the certificate template because a basic permission had been removed from the template: Authenticated Users — Read.

The requested template OID was:

1.3.6.1.4.1.311.21.8.4730629.14882920.7291564.14825634.11292136.38.10267230.1384975

which correctly mapped to:

Toyo Member Server IPSec

So the template existed. The request referenced the correct template. The CA had previously issued certificates from it.

The important line was:

The ToyoMemberServerIPSec Certificate Template could not be loaded.

Check that the template really exists

You can query the certificate templates directly from Active Directory.

$Base = "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=TOYO,DC=LOC"

Get-ADObject `
    -SearchBase $Base `
    -LDAPFilter "(objectClass=pKICertificateTemplate)" `
    -Properties displayName,msPKI-Cert-Template-OID |
Where-Object {
    $_.DisplayName -eq "Toyo Member Server IPSec"
} |
Select-Object Name,DisplayName,msPKI-Cert-Template-OID

In this case the result was correct:

Name                  : ToyoMemberServerIPSec
DisplayName           : Toyo Member Server IPSec
msPKI-Cert-Template-OID :
1.3.6.1.4.1.311.21.8.4730629.14882920.7291564.14825634.11292136.38.10267230.1384975

That also rules out one common problem: an old template being deleted and recreated with the same display name but a different OID.

Check whether the CA is issuing it

From the CA:

certutil -CATemplates

Or specify the CA explicitly:

certutil -config "TOYONUC01.TOYO.LOC\TOYO-TOYODC01-CA" -CATemplates

You can also query the CA object in Active Directory:

$Base = "CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=TOYO,DC=LOC"

$CA = Get-ADObject `
    -SearchBase $Base `
    -LDAPFilter "(cn=TOYO-TOYODC01-CA)" `
    -Properties certificateTemplates,dNSHostName

$CA.certificateTemplates | Sort-Object

ToyoMemberServerIPSec should appear in the list.

If it does not, publish it from:

Certification Authority
  > Certificate Templates
  	> New
  	  	> Certificate Template to Issue

If it is already published, check the template permissions.

The actual fault

On the affected template, Authenticated Users had been removed.

The CA therefore could not correctly load the template from Active Directory.

Check the ACL with PowerShell:

$Template = Get-ADObject `
    -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=Domain,DC=com" `
    -LDAPFilter "(cn=TemplateName)"

(Get-Acl "AD:$($Template.DistinguishedName)").Access |
    Select-Object `
        IdentityReference,
        ActiveDirectoryRights,
        AccessControlType,
        IsInherited |
    Format-Table -AutoSize

Look for:

NT AUTHORITY\Authenticated Users

with Read permission.

Authenticated Users does not need to be allowed to enroll, a typical permission set might be:

Authenticated Users
    Read

Member Server Certificate Group
    Read
    Enroll
    Autoenroll

The dedicated server group controls who is allowed to obtain the certificate.

Authenticated Users : Read allows the template to be discovered and read correctly by the AD CS infrastructure.

The fix

Open:

certtmpl.msc

Open the affected template and select:

Security

Add:

Authenticated Users

and grant:

Read

Do not grant Enroll or Autoenroll unless that is genuinely intended.

The servers or groups that should receive the certificate should retain their own:

Read
Enroll
Autoenroll

After correcting the template, allow AD replication to complete.

You can force the CA to reload its configuration by restarting Certificate Services:

Restart-Service CertSvc

Be aware that this temporarily stops certificate issuance.

Then on an affected client:

gpupdate /force
certutil -pulse

certutil -pulse triggers certificate autoenrollment processing.

Check the enrollment policy as well

If there is any uncertainty about how the client is obtaining certificate policy, this is useful:

Get-CertificateEnrollmentPolicyServer -Scope All -Context Machine |
    Format-List *

For normal domain enrollment you will usually see something similar to:

Url                     : LDAP:
AuthType                : Kerberos
AutoEnrollmentEnabled   : True
IsDefault               : True
Context                 : Machine

That confirms the machine is using the normal Active Directory enrollment policy rather than Certificate Enrollment Web Services.