Error 0x80094012: certificate template permissions deny the enrolling account

Fix it now

0x80094012 is CERTSRV_E_TEMPLATE_DENIED: the permissions on the certificate template do not allow the current user to enrol for this type of certificate. Nothing is wrong with the key, the request or the certification authority. Its neighbour 0x80094011 is the same refusal one level up, at the CA itself.

certutil -template
certutil -CATemplates
gpupdate /force
certutil -pulse

1. Work out which account is really enrolling. For a computer certificate that is the machine account, not the person at the keyboard – and a machine only picks up new group membership after a reboot.
2. Open the certificate templates console from the Certification Authority console: right-click Certificate Templates and choose Manage. Find the template and open its Security tab.
3. Grant the requesting principal – ideally a group – both Read and Enroll. Add Autoenroll as well if autoenrolment is meant to issue this certificate.
4. Then check the CA itself: in the Certification Authority console, open the properties of the CA and its Security tab, and confirm the same principal has Request Certificates.
5. Refresh membership and retry: reboot a computer, or sign out and back in for a user, then gpupdate /force followed by certutil -pulse.

Microsoft’s published minimum is precise: the requesting user or machine needs Read and Enroll on the template, and Read on the certification authority object. Anything less produces this code.

If the certificate issues, you are finished. The next section covers the cases where the permissions look right and enrolment still fails.

Why it happens

Enrolment permission is checked in two places and people usually look at one. The certificate template is an Active Directory object with its own security descriptor, and the certification authority has a security tab of its own. A principal that can reach the CA but has no Enroll right on the template gets 0x80094012; a principal with template rights but no rights at the CA gets 0x80094011, CERTSRV_E_ENROLL_DENIED, which says the permissions on this certification authority do not allow the current user to enrol for certificates.

The identity being checked is the thing to establish first. A machine certificate is requested by the computer account, so granting the administrator who is testing it Enroll rights changes nothing. Group membership is equally literal: a computer added to a group does not have that membership until it reboots, and a user does not have it until they sign in again, because the token was built at logon.

Two other codes in this family look like permission problems and are not. 0x80094009 is CERTSRV_E_RESTRICTEDOFFICER, an operation denied because it can only be performed by a certificate manager who is allowed to manage certificates for that requester – a certificate manager restriction on the CA rather than an enrolment right. 0x80094807 is CERTSRV_E_BAD_TEMPLATE_VERSION, the request template version is newer than the supported template version, which is a capability mismatch and no amount of ACL editing will fix it.

Full reference

The four codes side by side

The permission set that actually has to be there

Do not remove Authenticated Users from a template’s ACL without adding every CA computer account with Read. Authenticated Users includes the certification authority object itself, and if the enterprise CA can no longer read the template in Active Directory, requests against it fail – with a different code, 0x80094800, and a warning on the CA at service start.

Checking from the client rather than the console

• certutil -template lists the enrolment policy templates as the client sees them, which is the fastest way to tell whether the client can see the template at all.
• certutil -CATemplates run on the CA lists what that CA is configured to issue.
• certutil -pulse triggers an autoenrolment cycle without waiting.
• If the template appears for one user and not another, the difference is a group membership and a token, not the template.

Group membership and tokens

This is the single most common reason a correct permission change appears not to work. Windows builds the access token at logon, and adds group memberships to it then. A user added to a group half an hour ago is not in that group as far as any running session is concerned, and a computer added to a group is not in it until it restarts. Before you go back to the template and add another entry, sign out or reboot and try once more.

Design notes worth writing down

• Grant enrolment rights to groups, never to individual users or computers. The ACL is a template-wide object and it becomes unreadable quickly.
• Keep one template per purpose. Templates that serve two purposes end up with permission sets that grant more than either purpose needs.
• Record which group holds Enroll on which template somewhere outside the console, because the console is a poor audit trail.
• Where a template supersedes an older one, check the permissions on both: the old one usually still issues.

Every code this article covers

Confirm the fix worked

1. The certificate issues to the intended principal on a machine that was failing.
2. The template’s Security tab shows Read and Enroll for a group containing that principal.
3. The CA’s Security tab shows Request Certificates for the same group.
4. certutil -template on the client lists the template.
5. For autoenrolment, certutil -pulse produces the certificate without a manual request.

Questions people ask about this