0X8009400C

CERTSRV_E_BAD_REQUEST_KEY_ARCHIVAL (0X8009400C) Fix

This error means the certificate request has a messed-up key archival blob. Usually it's a template mismatch on the CA. Here's how to fix it.

Cause #1: Wrong CA template — key archival not enabled

The most common reason for 0X8009400C is you're submitting a request to a CA that expects key archival, but the template you're using doesn't have the Archive subject's private key option checked. What's actually happening here is the CA tries to decrypt the archival blob from the request, but the blob is either missing or formatted for a different template, so it throws this error.

I've seen this most often when someone creates a custom template based on the Exchange Enrollment Agent (Offline request) template, forgets to enable key archival, and then wonders why certreq fails. The CA sees a request that claims to be for a template with archival, but the blob isn't there.

Fix: Open the Certificate Templates console (certtmpl.msc). Right-click your template, choose Properties, go to the Request Handling tab. Check Archive subject's private key. If it's greyed out, you need to first set the Key Recovery Agent certificate on the CA — see Cause #2.

# Quick check: list templates with key archival on CA (PowerShell)
Get-CATemplate | Where-Object {$_.pkiEnforceKeyArchival -eq $true} | Select-Object Name

If no templates show up here, that's your problem. The template you're using isn't marked for archival, but the request is trying to use it that way.

Cause #2: Missing or expired Key Recovery Agent (KRA) certificate

Even if your template has key archival enabled, the CA must have at least one valid KRA certificate installed. The KRA is the certificate the CA uses to encrypt the private key for recovery later. No KRA, no archival — and the CA rejects the request with 0X8009400C because it can't construct the encrypted blob.

This happens a lot after a CA migration or rebuild. The old KRA cert is gone, and nobody set up a new one. Or the existing KRA expired — and yes, that will break all new certificate enrollments that require archival.

Fix: On your CA server, open the Certification Authority console. Right-click your CA, choose Properties, go to the Key Recovery Agents tab. If the list is empty or has only expired certs, you need to enroll a new KRA certificate.

  1. Open Key Recovery Agent template — it's in the same template console. Make sure it's issued by your CA.
  2. Enroll a KRA cert: certreq -new -q kra.inf kra.req (create a simple INF with Subject = your server name)
  3. Submit it: certreq -submit -q kra.req kra.cer
  4. Install it: certreq -accept kra.cer
  5. Back in CA Properties > Key Recovery Agents, add this cert. Mark it as Authorized.

Once the KRA is in place, restart the CA service (net stop certsvc && net start certsvc) and try your request again.

Cause #3: The request itself is malformed — bad PFX or P12 export

Less common but when it does hit, it's a nightmare to debug. The error can also come from the client side if the .pfx or .p12 file you're using to generate the request has its private key stored in a format the CA doesn't understand. This usually happens when you export a certificate from a third-party tool (like OpenSSL) with non-standard key encryption.

What's actually happening here is the CA expects the private key to be wrapped in a specific ASN.1 structure (PKCS#7 with enveloped data). If your export added extra attributes or used a different cipher, the CA can't parse the archival blob and spits out 0X8009400C.

Fix: Re-export the PFX using Windows built-in tools. Open certlm.msc, find the certificate, right-click > All Tasks > Export. Choose Yes, export the private key, check Include all certificates in the certification path if possible, and set a strong password. Then regenerate your request. If you absolutely must use OpenSSL, stick to pkcs12 -export -inkey key.pem -in cert.pem -out bundle.pfx -legacy to keep it compatible with Windows.

Here's a quick test: convert the PFX to a request using certreq and see if it barks at you:

certreq -new -q my.pfx my.req

If that command fails with a different error (usually 0x8009000d), the PFX is corrupt. Fix the export first.

Quick-reference summary table

Cause What to check Fix
Template lacks key archival Template properties > Request Handling Check Archive subject's private key and reissue template
No valid KRA certificate CA Properties > Key Recovery Agents tab Enroll and authorize a new KRA cert, restart CA service
Malformed PFX/P12 export Try certreq -new -q my.pfx my.req Re-export using Windows certlm.msc with standard settings
Related Errors in Cybersecurity & Malware
0X000006D5 Fix RPC_S_INVALID_AUTH_IDENTITY 0x000006D5 Error in Windows 0X00001783 Fix 0X00001783: File encrypted, open in client-side encryption mode Kill Emotet on Windows: The Only Fix You Need Stop Chrome pop-up ads: adware removal guide (2025)

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.