CRYPT_E_NO_DECRYPT_CERT (0X8009200C) Fix: Missing Private Key

Cause 1: You imported the certificate without the private key

This is the most common reason you see error 0x8009200C. You double-clicked a .cer or .crt file, clicked "Install Certificate", and Windows put it in the store. But that file only had the public key – no private key. The OS can't decrypt anything without a matching private key.

What's actually happening here is Windows looks up the certificate by thumbprint, finds it, but when it tries to access the associated private key, there's nothing there. The error code 0x8009200C literally means "cannot find the certificate and private key to use for decryption".

How to fix it

1. Get the correct .pfx or .p12 file from whoever issued the certificate. This file must contain both the public certificate and the private key.
2. Double-click the .pfx file. The Certificate Import Wizard opens.
3. Choose "Local Machine" store (not Current User) unless you're sure the app runs under your user account.
4. When asked for the password, type the one they gave you. Check "Mark this key as exportable" if you might need to back it up.
5. Place it in "Trusted Root Certification Authorities" or "Personal" store depending on your use case (IIS needs Personal, root CAs need Trusted Root).

The reason step 3 matters: if you import to Current User store but the app (like IIS or a Windows service) runs as SYSTEM or a different user, it can't see that cert. Always pick Local Machine for server stuff.

Cause 2: Wrong certificate store (Current User vs Local Machine)

You have the private key – but it's in the wrong store. This happens often with IIS, EFS, or S/MIME email encryption.

IIS runs under the SYSTEM account or ApplicationPoolIdentity. These accounts don't have access to the Current User certificate store. Same goes for Windows services. If your certificate is in Current User\Personal but the website runs under SYSTEM, error 0x8009200C appears.

How to fix it

• Open certlm.msc (Local Machine certificates). Press Win+R, type it, hit Enter.
• Open certmgr.msc (Current User certificates). Same way.
• Compare the two stores. Look under Personal > Certificates. If the cert is in certmgr but not in certlm, that's your problem.

The fix is to export and re-import.

1. In certmgr.msc, find the certificate. Right-click > All Tasks > Export.
2. Choose "Yes, export the private key". If this option is greyed out, you don't have the private key at all – go back to Cause 1.
3. Set a password, save the .pfx file.
4. In certlm.msc, right-click Personal > All Tasks > Import. Browse to the .pfx, type the password, finish.

Now any service running under SYSTEM can access the cert. If you're using IIS, also check the binding: in IIS Manager, click your site, then Bindings. Make sure the HTTPS binding points to the correct certificate.

Cause 3: Corrupted or missing private key container in the registry

This one's trickier. The certificate itself looks fine, the private key appears in the MMC snap-in, but Windows still throws 0x8009200C. What's actually happening here is the registry key that maps the certificate to its private key container got deleted or corrupted.

I've seen this after a Windows update (KB5009543 on Server 2019 was a notorious one), or after a disk cleanup tool nuked the %ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys folder.

How to diagnose it

• Open certlm.msc, find the problematic certificate, double-click it.
• Go to the Details tab, scroll down to "Key Container". Copy the value – it looks like a GUID, something like {A1B2C3D4-...}.
• Open Regedit. Navigate to:

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb

• Look for a key whose name matches the GUID you copied. If it's missing, that's the cause.

How to fix it

1. Export the certificate with private key from certlm.msc (as shown in Cause 2). Save the .pfx somewhere safe.
2. Delete the broken certificate from certlm.msc.
3. Re-import the .pfx file. This creates a fresh registry entry.

If that doesn't work, check the MachineKeys folder: C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys. Look for a file with a name matching the GUID. If the folder is empty or the file is 0 bytes, you'll need to regenerate the keys – which usually means getting a new cert from your CA.

Quick-reference summary

If none of these fixes work, the certificate itself is probably broken. Ask your certificate authority for a new one. Don't waste time chasing ghosts – the error 0x8009200C is always about a missing or inaccessible private key. Period.