Fix CRYPT_E_BAD_MSG (0X8009200D) – the real fixes

Cause 1: Corrupted or mismatched digital signature file

This is the one I see most often. Someone is trying to verify a signed file—maybe a driver, an EXE, or a PowerShell script—and the .cat or .p7b file got corrupted during download or copy. Or the file itself was signed with a different certificate than expected. The error pops up because Windows says, This doesn't look like a proper cryptographic message to me.

Here's a real-world trigger: You download a driver from a vendor's site, but the download interrupted or the file got truncated. You run signtool verify /pa mydriver.cat and boom, 0X8009200D.

How to fix it

1. Open a Command Prompt as Administrator. Click Start, type cmd, right-click it, choose Run as administrator.
2. Run this command to check which signature file is attached:

   signtool verify /v /a yourfile.exe

   (replace yourfile.exe with your actual file path).
3. Look for a line like Signing certificate chain. If it says An error occurred while trying to read the signed message and throws 0X8009200D, the signature is corrupt.
4. Get a fresh copy of the file from the original source. Re-download it completely. Compare file hashes if you can—SHA256 hash should match the vendor's published value.
5. After you have the clean file, run the verify again:

   signtool verify /v /a yourfile.exe

   You should see Successfully verified and see the certificate chain listed.
6. If you don't have the original source, try removing the current signature file and re-signing it if you have the certificate. Use:

   signtool remove /v yourfile.exe

   Then re-sign with your certificate. That almost always clears the bad message error.

After this fix: The verify command returns Successfully verified: SHA256 hash matches. No more error code.

Cause 2: Corrupted or missing certificate store entries

Less common but real. The file's signature might be fine, but Windows can't read a certificate in your local machine's store. Happens after a disk cleanup, registry cleaner abuse, or a failed Windows update that nuked some Trusted Root store entries. You'll get 0X8009200D when trying to install a signed driver or open a signed document, and the file itself looks fine when verified on another PC.

How to fix it

1. Press Windows Key + R, type certlm.msc, hit Enter. This opens the Local Machine certificate store. You'll see a warning about making changes—you're doing this right.
2. Expand Trusted Root Certification Authorities and then click Certificates. Scroll through the list. Look for any certificate that shows a red X or says This certificate has expired or is not yet valid or Certificate status: revoked for a root CA that should be valid (like DigiCert, Microsoft Root Authority).
3. If you see a root CA that's expired or corrupted, right-click it, choose All Tasks, then Delete. Confirm the deletion.
4. Next, download a fresh copy of that root certificate from the CA's official site. For Microsoft certificates, use the Microsoft Update Catalog. I usually go to DigiCert's root certificate page if it's a DigiCert root.
5. Double-click the downloaded .cer or .crt file. In the Certificate dialog, click Install Certificate. Choose Local Machine (yes), then Place all certificates in the following store, browse to Trusted Root Certification Authorities, click OK, then Finish.
6. You should see a dialog: The import was successful.
7. Now try the operation that gave the error again. If it was a driver install, run it again. If it was a file verification, run signtool again.

After this fix: The error goes away because the certificate chain can now be built properly. The file verifies without issues.

Cause 3: Wrong encoding format on the cryptographic message

This one's a bit more technical, but it's the third most common cause I've seen in the field. The cryptographic message (like a PKCS#7 signature block) is stored in a file with the wrong encoding—like Base64 when it should be DER binary, or vice versa. Usually happens when someone manually extracted a signature from an email or a signed document and saved it as a .p7b without proper conversion. You'll get 0X8009200D when you try to import that .p7b into a certificate store or use it with signtool.

How to fix it

1. First, check what format your file is in. Open Notepad and drag the .p7b or .p7c file into it. If you see text starting with -----BEGIN PKCS7----- or MIME-Version: 1.0, it's Base64-encoded. If you see garbage characters, it's DER binary.
2. If it's Base64 but you need DER binary, use the CertUtil tool to convert. Open Command Prompt as Administrator and run:

   certutil -decode yourfile.p7b yourfile_der.p7b

   This decodes the Base64 to binary DER. After it runs, you should see Output location confirmed and Decode succeeded.
3. If it's DER binary but you need Base64 (for example, to embed in an XML or email), run:

   certutil -encode yourfile.p7b yourfile_base64.p7b

   You'll see Encode succeeded.
4. Now try to use the converted file. For instance, if you were trying to import the .p7b into the certificate store, double-click the converted file and click Install Certificate. It should work this time.
5. If you're still getting the error after conversion, the file itself might be corrupt or not a valid PKCS#7 message at all. Check the file size—a valid signature file should be at least a few hundred bytes.

After this fix: The import or verification succeeds because the encoding matches what the system expects.

Quick-reference summary table

If none of these work, you might be dealing with a system file corruption issue. Run sfc /scannow and dism /online /cleanup-image /restorehealth from an elevated command prompt. But in my experience, one of these three fixes handles 95% of 0X8009200D cases.