0X80095004

Fix XENROLL_E_RESPONSE_KA_HASH_MISMATCH (0x80095004)

Windows Errors Intermediate 👁 1 views 📅 May 27, 2026

Key archival hash mismatch in certificate enrollment. The request and server response don't agree on the public key. Fix starts with re-enrolling, ends with CA config changes.

What's happening here

XENROLL_E_RESPONSE_KA_HASH_MISMATCH (0x80095004) means the client sent a certificate request with a public key for archival, but the CA's response contains a different key hash than expected. The error surfaces during key archival — when the CA tries to archive the private key via a Key Recovery Agent (KRA).

You'll see this most often on Windows 10/11 or Windows Server 2016+ when enrolling a certificate from a template that has "Archive subject's private key" enabled. The enrollment kicks off, the CA processes the request, then at the very last step — during response validation — the client says "wait, the hash of the key you archived doesn't match what I sent."

The root cause is almost always one of three things: a stale template cache, a corrupted Key Recovery Agent certificate, or a mismatch between the CA's KRA configuration and the client's request.

Fix 1: Simple re-enroll (30 seconds)

Before you dig into the CA server, try this: delete the pending certificate request and re-enroll from scratch.

  1. Open certlm.msc (Local Machine certificate store).
  2. Go to Personal > Certificates.
  3. Look for any certificate with the status Pending or that shows the exact error in its details.
  4. Delete it. Right-click > Delete.
  5. Request the certificate again: right-click Personal > All Tasks > Request New Certificate.
  6. Pick the same template, complete enrollment.

If it works, you're done. The issue was a cached request with a stale nonce or bad state. If it fails again with the same error, move on.

Fix 2: Clear the template cache (5 minutes)

Windows caches certificate templates locally. If the template was updated on the CA (e.g., key archival settings changed) but your machine still has the old version, the hash mismatch appears.

  1. Close all MMC consoles and cert services.
  2. Open an elevated Command Prompt or PowerShell.
  3. Run: 
    certutil -delstore CA "TemplateName"
    Replace TemplateName with the actual template name causing the issue.
  4. Then clear the schema cache: 
    certutil -pulse
  5. Now re-enroll using the same steps as Fix 1.

This forces the client to download the current template definition from the CA. If the template's key archival settings changed after your last enrollment, this alone fixes it.

Still broken? Let's check the CA side.

Fix 3: Verify Key Recovery Agent configuration (15+ minutes)

The most common deeper cause: the CA's Key Recovery Agent certificate is expired, missing, or doesn't match the template's KRA settings. Here's how to check and fix it.

Step 3a: Check if KRA certs are installed on the CA

  1. On the CA server, open Certification Authority MMC.
  2. Right-click the CA name > Properties.
  3. Go to the Recovery Agents tab.
  4. You should see at least one Key Recovery Agent certificate listed. If the list is empty, you need to enroll a KRA cert first.

Step 3b: Enroll a new KRA certificate (if missing or expired)

  1. On the CA server, open certlm.msc.
  2. Go to Personal > Certificates.
  3. Look for any certificate with Intended Purpose "Key Recovery Agent". If it's expired or missing, request a new one.
  4. Right-click Personal > All Tasks > Request New Certificate.
  5. Select the Key Recovery Agent template. If you don't see it, you need to enable it in Certificate Templates MMC first.
  6. Complete enrollment. Then go back to CA Properties > Recovery Agents and add this certificate if not already listed.

Step 3c: Verify the template's KRA settings match

  1. Open Certificate Templates MMC (on the CA server or domain controller).
  2. Find the template your users are enrolling against.
  3. Right-click > Properties.
  4. Go to the Request Handling tab.
  5. Check Archive subject's private key is enabled.
  6. Go to the Recovery tab.
  7. Ensure Key recovery agent certificate is selected and points to a valid KRA template.

If you changed any settings here, you must reissue the template: right-click the template > Reissue. Then on the CA, right-click Certificate Templates > New > Certificate Template to Issue and pick the updated template. This pushes the changes.

Step 3d: Force ADS replication (domain environments)

If you're in a multi-domain controller environment, the CA might be using stale KRA data from AD. Run this on the CA server:

repadmin /syncall /AdeP

Then restart the CA service:

net stop certsvc && net start certsvc

Now try enrolling again on the client.

Why step 3c works

The key archival hash is computed from the client's public key and the KRA certificate used to encrypt the private key. If the CA tries to archive with a different KRA cert than what the client expected — even a different serial number for the same subject — the hash won't match. The client validates the hash before accepting the response, and 0x80095004 is the result.

Reissuing the template ensures all new enrollments reference the correct KRA certificate.

Last resort: Restart the CA server

If none of the above works, reboot the CA server. I've seen cases where a hung thread in the Certificate Services process holds a stale KRA handle, and only a full restart clears it. Yes, it's brute force. But sometimes that's the fix.

Was this solution helpful?

XENROLL_E_RESPONSE_KA_HASH_MISMATCH 0x80095004 key archival hash mismatch certificate enrollment error Windows CA key recovery agent NDES certificate template key archival hash mismatch fix PKI error