Fix CERTSRV_E_KEY_ARCHIVAL_NOT_CONFIGURED (0x8009400A)

Yeah, that error's annoying

You're enrolling for a certificate, everything looks fine, then bam — 0x8009400A. The CA refuses to archive the private key. The weird part? It's not a network issue or a bad request. The CA is literally saying “I can't do what you're asking because I'm not set up for it.”

The real fix: enable key archival

This error shows up when the certificate template requests private key archival (which is common for EFS or auto-enrollment scenarios) but the CA itself hasn't been configured to support it. You need to do two things:

1. Enable key archival on the CA server
2. Make sure the certificate template allows it

Step 1: Enable key archival on the CA

• Open the Certification Authority snap-in (certsrv.msc)
• Right-click your CA name and pick Properties
• Go to the Recovery Agents tab
• Click Enable key archival
• You'll be prompted to choose a key recovery agent certificate — if you don't have one yet, you'll need to request one. You can create a self-signed KRA cert using certreq -new or through the CA itself

A key recovery agent certificate is a special cert that allows the CA to decrypt archived private keys. Without it, the CA can't even store them. So pick one or create one. Then click OK.

Step 2: Check the certificate template

• Open the Certificate Templates console (certtmpl.msc)
• Find the template you're enrolling against
• Right-click it, pick Properties
• Go to the Request Handling tab
• Check the box Allow private key to be exported — this is required for archival to work
• Go to the Cryptography tab, and under Key archival, choose Archive subject's private key (should be selected by default if you're hitting this error)

If Archive subject's private key is greyed out or missing, it's because the template doesn't support it — you'd need to duplicate the template and pick a newer version that supports archival (like Windows Server 2008+ scheme).

Step 3: Restart the CA service

net stop certsvc && net start certsvc

After that, retry enrollment. The error should be gone.

Why this works

Here's what's actually happening: The client's enrollment request includes a flag saying “hey CA, please archive my private key.” This is common for EFS recovery or scenarios where you need to recover a user's encrypted files later. But the CA has a gate — it won't even attempt to store that key unless key archival is globally enabled and it has a valid KRA certificate. Without those two things, the CA returns 0x8009400A as a hard reject. The error isn't about the key being bad; it's about the CA refusing to do the archival work.

The reason step 3 works is that the CA service caches its key archival state in memory. A restart forces a clean reload of the configuration.

Less common variations

Sometimes you'll see this error even after enabling archival. Here are the edge cases I've run into:

• Multiple CA in a hierarchy: If you're enrolling against an issuing CA that's subordinate to another, key archival must be enabled on the root CA as well — because the KRA cert chain needs to validate up to the root. I've seen people enable it on the issuing CA but forget the root.
• KRA certificate expired: The error message doesn't tell you that the KRA cert itself expired. Check its validity in the CA's certificate store (under Certificates (Local Computer) -> Personal -> Certificates). If it's expired, request a new one and reassign it in the CA properties.
• Template permissions: Rare, but if the enrolling user doesn't have Read/Enroll on the template, the CA may throw this error instead of a more obvious access-denied. Audit the template ACL — give domain users at least Read and Enroll.
• Group Policy blocking archival: If you've set Group Policy to disable key archival (yes, that exists under Computer Configuration -> Administrative Templates -> Windows Components -> Certificate Services), it overrides the CA setting. Check GPO, remove or disable that policy.

Prevention: set it up before you need it

The easiest way to avoid this headache is to enable key archival when you first deploy the CA or at least before you issue any templates that require it. Most people don't — they set up the CA, then later add an EFS template, then get the error. A two-minute config check saves you the scramble.

Also, set a reminder to renew the KRA certificate before it expires. I tag the KRA cert's expiration date in my calendar with a 30-day warning. When it expires, enrollment fails for any template with archival enabled, and users can't get their certificates until you fix it.

Finally, if you're not using EFS or some other feature that requires private key recovery, don't enable archival on the template at all. It's an unnecessary dependency. Keep templates simple — only ask for what you actually need. That alone will sidestep 0x8009400A entirely.