I know this error is infuriating—especially when you're in the middle of rolling out certificates and everything grinds to a halt with that long hexadecimal number. The good news: it's a config mismatch, not a hardware failure. Here's the fix.
The Quick Fix
Open the Certification Authority snap-in. Right-click the failed request under Pending Requests and choose All Tasks → Resubmit Request. It'll likely fail again, but that's fine—we're just confirming the error code. Now go to the template:
- Open Certificate Templates Console (run
certtmpl.msc). - Right-click the template you're using and choose Properties.
- Go to the Issuance Requirements tab.
- Look at Number of authorized signatures. That's the RA signature count. If it's set to 3, 5, or anything above 1, that's your culprit.
- Change it to 0 (if you want automatic approval after submission) or 1 (if you want one human stamp). Don't go higher unless you have a specific workflow for multiple RA signatures.
- Click OK. Then go back to Certification Authority, resubmit the pending request, and issue it.
That's it. Error gone, certificate issued.
Why This Happens
Windows Server 2016, 2019, and 2022 all enforce a hard limit on the number of RA (return authorization) signatures a certificate template can require. The default varies by OS version, but I've seen templates that were imported from older ADCS builds carrying a signature count of 3, 5, or even 10. Your CA chokes because it expects fewer. The error 0x80094815 literally translates to "The certificate template requires too many return authorization (RA) signatures".
The RA signature count controls how many separate approvers must digitally sign a certificate request before the CA issues it. Real-world scenario: a hospital network with multiple tiers of approval. But if you're just setting up a standard web server certificate or a domain controller certificate, you don't need multiple signatures. Most environments never use this feature. The CA says "I won't issue this—it's asking for more approval steps than I can handle."
Less Common Variations
Sometimes the error pops up but the template shows 0 for authorized signatures. That's weird, right? Check the Subject Name tab. If you've set Supply in the request and also enabled private key archival, the CA can still require an RA signature even when the count is 0. In that case, set the signature count to 1 explicitly, and make sure the enrollment agent certificate is trusted by the CA.
Another variant: the error shows on a subordinate CA but not the root. The subordinate CA might have a different template version cached. Run certutil -v -config on both CAs and compare the template definitions. If they don't match, update the subordinate CA's template by re-importing or restarting the CA service.
I've also seen this when someone tries to enroll a certificate with a smart card-based template on a CA that wasn't configured for smart card enrollment. In that case, you might also see 0x80094805 alongside. The fix is the same: drop the signature count to 0 or 1, and issue the certificate manually if needed.
Prevention
Set your template's RA signature count to 0 unless you have a real approval workflow. Most sysadmins don't need multiple signatures—it adds complexity without benefit. If you do need approvals, use a separate certificate manager role instead of fiddling with signature counts. Simpler, more reliable.
Also, keep an eye on template versions when you upgrade your CA. I've seen templates carry forward old settings from Windows Server 2012 R2 that break on 2019. Before you deploy a template to a new CA, check the Issuance Requirements tab. One quick look saves you a support call.
If you're building an automated enrollment system, test with one request first. I always use a dummy template with signature count 0 before rolling out to production. Saves me from this exact headache.