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.
- Open Key Recovery Agent template — it's in the same template console. Make sure it's issued by your CA.
- Enroll a KRA cert:
certreq -new -q kra.inf kra.req(create a simple INF with Subject = your server name) - Submit it:
certreq -submit -q kra.req kra.cer - Install it:
certreq -accept kra.cer - 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 |