Fix 0X8009200B: Missing certificate and private key for decryption

Yeah, this error is a pain. You're trying to decrypt an email, open an encrypted file, or bind a certificate in IIS, and Windows just says nope. The exact message is CRYPT_E_NO_KEY_PROPERTY (0X8009200B) - Cannot find the certificate and private key for decryption. It's frustrating because the certificate looks fine in the store—you can see it, it's there—but the private key is missing or detached. I've seen this most often after someone migrates a certificate between machines, or exports it as a DER or CER file instead of a PFX. Let's fix it.

The quick fix: Re-import the PFX with the private key marked as exportable

This is the fix that works 9 times out of 10. You need the original certificate as a PFX/PKCS12 file that includes the private key. If you don't have one, you'll need to get that from whoever issued the certificate or export it again from the original machine.

1. Open certlm.msc (for local machine) or certmgr.msc (for current user) depending on where you need the certificate. You'll get a UAC prompt for certlm.msc.
2. Go to Personal > Certificates. Find your certificate. Right-click it and select Delete. Yes, delete it. We're starting fresh.
3. Now, right-click on the Personal folder (the folder itself, not a cert) and choose All Tasks > Import.
4. Click Next. Browse to your PFX file. Select it, click Next.
5. Type the password for the PFX file. Here's the critical part: check the box that says "Mark this key as exportable". This is not always checked by default, and skipping it often causes the private key to not attach properly in certain scenarios. Also check "Include all extended properties" if you see it.
6. Select Automatically select the certificate store based on the type of certificate. Click Next, then Finish.
7. You should see a popup saying "The import was successful."

Now double-click the certificate in the store. Go to the General tab. At the bottom, it should say "You have a private key that corresponds to this certificate." If that text is missing or says "No private key available", the import didn't work—repeat the steps carefully.

After this, try whatever decryption operation you were doing. The error should be gone.

Why this works

The core issue is that Windows stores certificates and private keys as separate objects. When you import a certificate without the private key (like a .cer file), you get the public part only. The decryption operation needs the private key to work. Even when you import a PFX, Windows might not link the private key properly if the import wizard doesn't mark it as exportable—or if the original export was done without the private key. By deleting the orphaned certificate and re-importing with the right flags, you force Windows to create a fresh private key container and link them correctly.

Less common variations and their fixes

Sometimes the re-import fix doesn't solve it. Here are other scenarios I've run into.

1. Certificate was exported without the private key

If the PFX file itself doesn't contain the private key, no amount of re-importing will help. How to check: Open a command prompt and run certutil -dump yourfile.pfx. Look for "Private Key" in the output. If you see "No private key", you need to get a proper export from the original machine. On the original machine, use certlm.msc, right-click the certificate, choose All Tasks > Export, select Yes, export the private key, and follow the wizard. The resulting PFX will have the key.

2. Private key permissions are wrong (common in IIS scenarios)

If you're using the certificate in IIS (like for HTTPS binding), the application pool identity needs read access to the private key. Fix: In certlm.msc, right-click your certificate, choose All Tasks > Manage Private Keys. Add the account that IIS runs under (like NETWORK SERVICE or a custom app pool identity) with Read access. Then restart the site.

3. The certificate was imported to the wrong store

Some applications look for certificates in specific stores. For example, IIS uses the Local Machine > Personal store, while Outlook for S/MIME uses Current User > Personal. If you imported to the wrong one, the app won't find the private key. Move the certificate using Certificates snap-in in MMC, or simply delete and re-import to the correct store.

4. CryptoAPI vs. CNG key storage

Older certificates use CryptoAPI (CSP) keys, newer ones use CNG (Key Storage Provider). If your application expects one but gets the other, you get this error. The fix: Export the certificate as a PFX with a password, then import it using certutil with the -csp flag if needed. In most cases, re-importing through the GUI handles this. But if it persists, try certutil -importPFX -user myfile.pfx for the user store, or certutil -importPFX -machine myfile.pfx for the local machine store.

How to avoid this error in the future

Prevention is straightforward. When exporting certificates, always choose Yes, export the private key and check Include all certificates in the certification path if possible. Set a strong password. Keep the PFX file in a secure backup location. If you're moving a certificate between servers, never use the .cer format—always use PFX.

Another pro tip: After importing a certificate, immediately verify it has a private key. Open the certificate and look for that line I mentioned earlier. It takes two seconds and saves you a headache later.

Lastly, if you manage multiple machines, consider using a certificate management tool or scripting the import with PowerShell. A quick script that imports a PFX with -Exportable flag can prevent manual mistakes. Here's a skeleton:

$pfxPath = "C:\certs\yourcert.pfx"
$password = ConvertTo-SecureString "yourpassword" -AsPlainText -Force
Import-PfxCertificate -FilePath $pfxPath -CertStoreLocation Cert:\LocalMachine\My -Password $password -Exportable

Run that as admin. It's reliable and repeatable.