Error 0x80094800: the CA does not support the requested certificate template

Fix it now

0x80094800 is CERTSRV_E_UNSUPPORTED_CERT_TYPE: the requested certificate template is not supported by this CA. Usually the template exists in Active Directory and was never published to this CA, which takes two minutes. The other cases are a template the CA cannot read, or one built for a newer CA than you are running.

certutil -CATemplates
certutil -SetCATemplates +WebServerV2
certutil -CATemplates

1. Read the first certutil -CATemplates output. If the template is not listed, this CA is not configured to issue it and that is your answer.
2. Publish it from the console if you prefer: in the Certification Authority console, right-click Certificate Templates, choose New, then Certificate Template to Issue, and select it.
3. From the command line use certutil -SetCATemplates +<TemplateName> with the template’s internal name, not its display name.
4. If the template does not appear in the list of templates you can add, open its Compatibility settings and compare the Certification Authority level with the CA you are running.
5. Retry the request, then check the CA’s Failed Requests view if it still does not go through.

There is a third possibility that catches people out: if Authenticated Users has been removed from the template’s ACL, the CA itself can no longer read the template in Active Directory, and clients see exactly this code.

If the template now appears in the CA’s list and the request succeeds, stop here. The next section covers the two cases where publishing does not help.

Why it happens

An enterprise CA issues only the templates it has been configured to issue. The template object lives in Active Directory and is visible forest-wide, so a client can see and request a template that this particular CA has never been told about. What comes back is CERTSRV_E_UNSUPPORTED_CERT_TYPE, and on the CA the policy module records a denied request.

The second cause is a permissions problem wearing the wrong error message. Microsoft documents that removing the Authenticated Users group from a template’s access control list stops the enterprise CA reading that template in Active Directory – the CA object is itself covered by that group – and requests against the template then fail. The published fix is that every CA’s computer account must be added to the template ACL with Read. On the CA you also see a warning at service start saying the template could not be loaded.

The third cause is version. A template carries compatibility settings for the certification authority and for the certificate recipient, and a template built for a newer CA than you are running cannot be issued by it – the template will not even appear in the list of templates you can add. That is a capability boundary rather than a configuration one.

Full reference

The codes in this family

What the CA logs while the client sees the error

Those two events split the diagnosis cleanly. A 53 with this code and no 77 means the template exists and is readable but is not published on this CA. A 77 at service start means the CA could not load the template at all, which is the Authenticated Users case.

Display name and internal name

certutil -SetCATemplates takes the template’s internal name, which is frequently not what the console shows. A template displayed as “Contoso Web Server (2019)” may have an internal name with no spaces at all. Read it from certutil -template output or from the template’s properties before scripting anything, because a mistyped name silently publishes nothing.

Requests that arrive with no template at all

0x80094801 says the request contains no certificate template information. That is normal for a request generated outside Windows – an appliance, an OpenSSL command line, a load balancer – which has no idea that templates exist. The supported route is to submit it against a named template with certreq -submit -attrib "CertificateTemplate:<name>", rather than to make the CA guess.

Key length refusals

0x80094811 is a different refusal that often follows a template change: the public key in the request does not meet the minimum size the template requires. Devices that generate keys in hardware are the usual source, because their key size is fixed by the firmware. Raise the request’s key size if you can, and if you cannot, the decision is whether that device belongs in your PKI at all rather than whether to lower the template’s floor.

Every code this article covers

Confirm the fix worked

1. certutil -CATemplates on the CA lists the template by its internal name.
2. A test request against that template issues rather than being denied.
3. No new Event ID 53 for that template in the CA’s log.
4. No Event ID 77 at Certificate Services start-up naming the template.
5. In a multi-CA environment, the template is published on every CA clients can reach.

Questions people ask about this