Fix CERTSRV_E_INVALID_CA_CERTIFICATE (0x80094005) on Windows Server

What causes this error

You see CERTSRV_E_INVALID_CA_CERTIFICATE (0x80094005) when the CA service starts or when you try to issue a cert. The message says "the CA's certificate contains invalid data." What's actually happening here is that the CA certificate stored in the AD database doesn't match what the local registry expects. This usually happens after you restore a CA from backup, or when someone manually edited the registry or the CA database got corrupted.

The error is common on Windows Server 2016 and 2019, especially after a system restore or moving the CA to a new machine. The fix depends on how bad the damage is. Let's go from easy to hard.

Fix 1: Reimport the CA certificate (30 seconds)

This is the simplest fix. The CA might have a valid certificate file but the service can't read it from the registry. You just tell it to re-read the file.

1. Open an elevated Command Prompt (Run as Administrator).
2. Run certutil -repairstore my "". Replace <thumbprint> with the thumbprint of the CA certificate. To get the thumbprint, run certutil -store my and copy the hash under the CA cert.
3. If that fails or you don't see the cert, stop the CA service: net stop certsvc.
4. Then run certutil -importPFX my C:\Path\To\YourCA.pfx. You'll need the PFX file from the original CA backup.
5. Start the service: net start certsvc.

Why this works: The repairstore command fixes the registry view of the certificate. If the file is intact but the registry pointer got corrupted, this rebuilds the link. If you don't have the PFX, skip to Fix 2.

Fix 2: Rebuild the CA using the existing certificate (5 minutes)

If the reimport didn't work, the CA database file (EDB) might be fine but the CA configuration in the registry is hosed. You can rebuild the CA from the existing cert and database.

1. Back up the CA database and keys. This is critical. Run certutil -backup C:\CABackup.
2. Uninstall the Active Directory Certificate Services role. Go to Server Manager > Manage > Remove Roles and Features. Uncheck "Certification Authority" and remove it. Don't delete the database.
3. Reboot the server.
4. Reinstall the CA role. During the install wizard, choose "Use existing certificate and private key." Point it to the PFX or the cert thumbprint from the backup.
5. When asked about the database location, point it to the same folder from the backup (usually C:\Windows\system32\CertLog).
6. Finish the install. The CA should start up with the old database and cert.

The reason step 5 works is that the CA service reads both the registry and the database. If the database has the right cert serial number, and the registry now matches, the error goes away.

Fix 3: Manually patch the CA certificate blob in AD (15+ minutes)

This is for when the CA is an enterprise CA and the cert is stored in Active Directory. You'll need to fix the binary blob that AD holds for the CA certificate. This is risky — do it only if the first two fixes failed.

1. Export the current bad cert from the CA machine: certutil -ca.cert C:\badcert.cer.
2. On a working CA (or the same machine after a clean install), export a good cert with certutil -ca.cert C:\goodcert.cer.
3. Compare the two files using a hex editor (like HxD). Look at the first few bytes. The bad cert often has extra padding or missing ASN.1 tags.
4. Use ADSI Edit to modify the CA object. Open adsiedit.msc, connect to Configuration partition. Navigate to CN=Servers, CN=Enrollment Services, CN=Public Key Services, CN=Services, CN=Configuration. Find your CA.
5. Right-click > Properties. Find the attribute cACertificate. This holds the binary blob.
6. If you have a good cert file, you can replace the blob: certutil -setreg CA\cacertificate @C:\goodcert.cer. Then restart the CA service.

What's happening here is that the cACertificate attribute in AD got corrupted during a bad replication. The CA reads this blob on startup. Replacing it with a valid blob fixes the error. But be careful — if the CA database references a different cert serial, you'll get another error. In that case, you likely need to restore the database too.

When to give up and rebuild

If Fix 1 and 2 fail, and you're not comfortable with ADSI Edit, the cleanest path is to set up a new CA with a new key pair. You lose all issued certificates, but you gain a working system. Export any pending requests before you nuke it.

The real fix for most people is Fix 2. Don't waste time on Fix 3 unless you absolutely need the existing CA name and keys. Most of the time, the database is fine and the registry is the problem.