You submit a certificate request and the CA spits back 0x80094810. Annoying, especially when the template looks fine.
The fix
This error means the CA is looking for an archived private key that doesn't exist (or can't be recovered). The certificate template has Archive subject's encryption private key enabled, but there's no matching key in the CA's key recovery database for the account or device making the request.
Here's what to do, in order.
1. Confirm the template setting
Open certtmpl.msc on a machine with the AD CS management tools. Find the template your request is using, right-click, pick Properties, then the Request Handling tab. Look at the checkbox labeled Archive subject's encryption private key. If it's checked and you don't actually need key recovery for this template, uncheck it. That alone fixes the error for most people.
After you click Apply, you need to publish the updated template on the CA. On the CA server, open certsrv.msc, right-click Certificate Templates, choose New > Certificate Template to Issue, and re-add the template so the change takes effect. You should see it in the list with a fresh timestamp.
2. If you do need key archival, configure a KRA
Key archival won't work without a Key Recovery Agent certificate. A lot of admins enable the template checkbox and never set up the KRA, then wonder why every request blows up.
On the CA, right-click the CA name, pick Properties, go to the Recovery Agents tab, and add at least one KRA cert. The KRA account needs the Key Recovery Agent template issued to it first. You can request it from the Certificates MMC (certlm.msc) on the CA itself or from any domain machine.
Once the KRA cert is in place, requests that ask for archival will succeed because the CA now has someone to hand the wrapped key to.
3. Stop reusing old requests
If you generated the .req/.inf file before fixing the template or KRA, that request is dead. The CA can't retroactively archive a key it never received. Delete the old request file and generate a new one:
certreq -new request.inf newrequest.req
certreq -submit -config "CA-Server\CA-Name" newrequest.req newcert.cerAfter the submit command, you should see either a success message or an Issued status. If it still returns 0x80094810, the template being hit isn't the one you think it is. Check the CertificateTemplate OID in the request file.
4. Verify the CA's key recovery database
If this used to work and stopped, check the CA database for the archived key. Open certsrv.msc, right-click the CA, pick View > Issued Certificates, and look at recent requests. For archived ones, the request's private key should have a matching entry in the key recovery store. If the database is toast or was restored from an old backup, requests fail with 0x80094810 across the board.
Run this on the CA to check the database health:
certutil -view -restrict "Disposition=20" -out "RequestID,RequesterName,NotBefore"You should get a list of issued and archived certs. If the list is empty or errors out, the database is the problem, not the template.
Why this works
Key archival isn't magic. When a client requests a cert with archival enabled, it sends the CA a private key wrapped with the KRA's public key. The CA stores that wrapped blob in its database. Later, if you need to recover the key, you use the KRA's private key to unwrap it.
The 0x80094810 error fires in certsrv.exe when the request says "archive this" but the CA either has no KRA to wrap to, or can't find a previously stored archived key to hand back. When you fix the KRA config or turn off the archival requirement, the CA has what it needs to complete the request, so the error goes away.
Less common variations
Template cached on the client
Windows caches certificate templates. After you change the template on the CA, clients can still see the old version for up to 24 hours. Force a refresh with:
certutil -pulseThen retry. You should see the new template properties in the enrollment UI.
Wrong template version
If you're using an old v1 template (the kind that shows up in certsrv as version 1.0), properties like key archival can't be edited from the GUI. Duplicate it to v2 or v3 first. V1 templates are legacy junk and Microsoft has been trying to kill them off since Server 2003.
Permissions on the KRA cert
The CA service account needs read access to the KRA certificate's private key. On the CA, open certlm.msc, find the KRA cert, right-click All Tasks > Manage Private Keys, and give the CA's service account (usually NT AUTHORITY\SYSTEM or your CA's gMSA) full control. After granting, restart the Certificate Services service with net stop certsvc && net start certsvc. The error should clear on the next request.
DCOM or RPC blocked
If the CA and the client are on different subnets and a firewall is blocking RPC dynamic ports, the enrollment call can time out mid-archive and surface as 0x80094810. Check Event Viewer > Applications and Services Logs > Microsoft > Windows > CertificateServicesClient-Lifecycle. A DCOM 10009 or RPC 1726 error right before the cert failure is your tell.
Prevention
- Set up your KRA before you enable archival on any template. Doing it in the other order means every request fails until you catch up.
- Only enable key archival on templates that actually need it. EFS recovery and a few smart card scenarios qualify. Plain web server certs don't.
- Back up the CA database and the KRA private key together. If you restore one without the other, 0x80094810 will haunt you.
- Test template changes in a lab CA first. Production CAs have a nasty habit of exposing every misconfiguration the moment a real user hits the enrollment page.
- Monitor the CertificateServicesClient-Lifecycle log on your CAs. Subscribe to it in Event Viewer and forward warnings and errors to your SIEM. You'll catch the next key-archival problem before users do.
Once the template and KRA are aligned, 0x80094810 stops showing up. If it comes back, it's almost always because someone touched the template or restored the CA from a stale backup.