XENROLL_E_RESPONSE_UNEXPECTED_KA_HASH (0X80095003) Fix

Cause 1: CA Template Has Key Archival Enabled But No Valid KRA Certificate

What's actually happening here is your client requests a certificate from a template that has key archival turned on. The CA then tries to encrypt the private key with a Key Recovery Agent (KRA) certificate before sending it back. But if the KRA certificate is missing, expired, or revoked, the CA can't complete the encryption. The hash it computes during archival doesn't match what the client expects—hence the 0x80095003.

I've seen this most often on Windows Server 2019 and 2022 CAs where someone enabled key archival on a template (like the Exchange Enrollment Agent (Offline request) or a custom smart card template) but forgot to issue or renew the KRA cert. The error pops up immediately during enrollment from any client—Windows 10/11, Server 2016+, doesn't matter.

The fix: Check and reissue the KRA certificate

1. Open Certification Authority MMC on the CA server.
2. Right-click your CA name → Properties → Recovery Agents tab.
3. You'll see a list of KRA certificates here. If the list is empty, or all entries show "Expired" or "Revoked", that's your problem.
4. Click Add to generate a new KRA certificate. You'll need to be a CA admin or have Issue and Manage Certificates permission.
5. Wait for the CA to publish the new KRA cert. This takes a minute—check the CertSrv log for errors.
6. Now retry the certificate enrollment. The client should get a properly archived key and the hash will match.

The reason this works is straightforward: the KRA certificate acts as the encryption key for the archived private key. Without a valid one, the CA can't produce a consistent hash across the client negotiation. The error code 0x80095003 specifically means the hash attribute in the response doesn't match—it's a cryptographic integrity check failing.

Cause 2: Corrupted or Mismatched Registry Key for Key Archival

Sometimes the CA itself is fine, but the client's registry has a stale or wrong setting for key archival attributes. This happens when you've moved a machine from one CA to another, or after an in-place upgrade of Windows. The client remembers the old CA's key archival parameters and rejects the new response.

I ran into this on a Windows 11 workstation that was migrated from an old 2012 R2 CA to a fresh 2022 CA. The old CA used SHA-1 for the archival hash; the new one used SHA-256. The client didn't update its registry, so it expected an SHA-1 hash, got SHA-256, and threw 0x80095003.

The fix: Delete or correct the client-side registry key

reg delete "HKLM\SOFTWARE\Microsoft\Cryptography\AutoEnrollment" /v KeyArchivalHash /f

Run this command as Administrator on the affected client machine. Then restart the Certificate Propagation service (CertPropSvc) from Services.msc or run:

net stop CertPropSvc && net start CertPropSvc

Now try enrollment again. If the registry key wasn't there, then this isn't your cause—skip to Cause 3.

If you want to check what the current value is before deleting, run:

reg query "HKLM\SOFTWARE\Microsoft\Cryptography\AutoEnrollment" /v KeyArchivalHash

The value will be a DWORD representing a hash algorithm OID. Common ones: 0x00008004 (SHA-1) or 0x0000800c (SHA-256). Deleting the key forces the client to renegotiate the algorithm with the CA on the next enrollment attempt. The CA sends its preferred algorithm, the client adapts, and the hash matches.

Cause 3: The CA Template Itself Is Misconfigured (Key Archival Wrongly Enabled)

This one is rarer but happens when someone copies a template that had key archival turned on—like the EFS Recovery Agent template—and uses it for a non-archival scenario. The template says "archive the key," but your client or application never intended to participate in key recovery. The CA does its job, the client gets a response with an archival hash it didn't ask for, and boom—error.

I've seen this with third-party PKI apps like an internal document signing system that requested certificates against a custom template. The template had the Archive subject's private key box checked under the Request Handling tab. It should have been unchecked.

The fix: Disable key archival on the template

1. Open Certification Authority MMC → right-click Certificate Templates → Manage.
2. Find the template your client is using. Right-click → Properties → Request Handling tab.
3. Uncheck Archive subject's private key.
4. Click OK and close the Templates console.
5. Back in the CA MMC, right-click Certificate Templates → New → Certificate Template to Issue and add the modified template (this re-issues it with updated settings).
6. On the client, request a new certificate. The response won't contain the archival hash attribute, so the error disappears.

The key insight: key archival is a feature, not a default. If you don't have a key recovery infrastructure (a dedicated key recovery server, KRA certificates, and a process for recovery), you shouldn't enable it. The error is the CA being honest—it tried to archive something, but the client couldn't verify the hash.

One more thing: If the CA is a standalone (not enterprise) CA, key archival isn't supported at all. The template option will be grayed out. If you're using a standalone CA and still getting this error, it's almost certainly Cause 1 or 2 above.