CERTSRV_E_TEMPLATE_DENIED (0x80094012): Why AD CS blocks your certificate request

When this error actually shows up

You're sitting at a Windows 10 or Windows Server 2022 machine, trying to enroll a certificate through Active Directory Certificate Services (AD CS). The Certificate Enrollment wizard fails with 0x80094012 — CERTSRV_E_TEMPLATE_DENIED. The event log on the CA server shows Event ID 53 from source CertificateServices. The client just says "The certificate request was denied by the certification authority."

I've seen this happen most often in two scenarios: (1) someone built a new certificate template and forgot to grant the Authenticated Users group the "Enroll" permission; or (2) the template has issuance requirements like "CA certificate manager approval" enabled, and nobody approved the pending request. It's never a CA health issue — it's always a template permissions or policy misconfiguration.

What's actually happening here

The CA itself is up, running, issuing other certificates just fine. The error is the CA saying: "I see your request, I see the template you want, but that template's security descriptor won't let you enroll, or the request doesn't satisfy the template's issuance policies."

Under the hood, the CA checks two things when it receives a request: (1) Does the requesting security principal have the Enroll permission on the template's ACL? (2) Does the request meet all issuance requirements (CA certificate manager approval, authorized signatures, application policies)? If either fails, you get 0x80094012. The CA logs the specific reason in its event log — that's your first debugging step.

The fix: step by step

You fix this from the CA server, not the client. You'll need Enterprise Admin or CA Admin rights.

1. Open the Certification Authority snap-in. Run certsrv.msc on the CA server. Expand the CA node and select "Issued Certificates". If the request is pending (for manager approval), you'll see it in "Pending Requests".
2. Check the CA event log. Open Event Viewer → Applications and Services Logs → CertificateServices. Look for Event ID 53 with your client's request ID. The message tells you exactly which permission or issuance condition failed. If the message says "permission denied" or "access denied", you're dealing with ACLs. If it says "issued by CA certificate manager required", it's issuance requirements.
3. Fix template permissions. Open certtmpl.msc. Right-click the template your client requested → Properties → Security tab. Make sure the security principal doing the enrollment (e.g., Domain Computers, Domain Users, or a specific service account) has Read and Enroll permissions. If the group is missing entirely, add it. Be precise: don't grant Enroll to Everyone unless you know what you're doing — that's over-permissive and a real security risk.
4. Check issuance requirements. Still in the template's Properties → Issuance Requirements tab. If "CA certificate manager approval" is checked, you must approve each pending request manually in the CA snap-in (Pending Requests folder, right-click → Issue). If "This number of authorized signatures" is set to anything other than 0, the client must include an authorized signing certificate in its request — most simple enrollment tools don't do this, and you'll need to either lower that number or educate the requester.
5. Publish the template if it's new. If you created a new template, you must publish it to the CA. In the CA snap-in, right-click Certificate Templates → New → Certificate Template to Issue. Select your template. Without this, the CA won't even see it — but you'd get a different error (CERTSRV_E_UNSUPPORTED_CERT_TYPE) in that case. Still, verify it's published.
6. Restart the client enrollment attempt. On the client, open certlm.msc (for machine context) or certmgr.msc (for user context), right-click Personal → All Tasks → Request New Certificate. If you fixed permissions, it should work now.

What to check when the fix doesn't work

If you've done all that and the error still fires, here's what's left:

• Check the request's subject name. Some templates require the subject to match a specific naming pattern or be supplied by the enrollee. If the client is auto-generating a subject that violates the template's constraints (like a blank CN or an invalid SAN), the CA will deny it — but the event log message will say "invalid request" or "subject name invalid", not just "permission denied". Double-check the event text.
• Verify the CA's certificate template permissions. There's a separate permission list on the CA itself (right-click the CA in certsrv.msc → Properties → Security tab). The enrolling user needs Read and Issue and Manage permissions on the CA? Actually no — Issue and Manage are for CA administrators. The enrollee only needs Request permission on the CA. But if someone accidentally removed Request for Authenticated Users at the CA level, no one can request any certificate template. That's rare but possible.
• Check if the template is in conflict with a group policy certificate enrollment policy. If you've deployed certificate enrollment via Group Policy (Computer Configuration → Windows Settings → Security Settings → Public Key Services → Certificate Enrollment Policy), and the policy tries to enroll a template that isn't published or the computer lacks permissions, you get 0x80094012 during auto-enrollment. In this case, the error happens silently in the background — check the CA's event log, not the client's UI.

In my experience, 9 out of 10 times it's the template security ACL not having the Enroll permission for the group doing the enrollment. The fix is to add it, restart the enrollment, and move on. The issuance requirement checkbox is the other common culprit — people check it thinking "I want to approve requests", and then forget to approve them. If you have manager approval, you must approve or deny each request — there's no auto-issuance.