ASN1 (0X80093101) CRYPT_E_INTERNAL_ERROR fix for cert installs

When this error hits

You're trying to import a certificate — maybe a wildcard SSL for an IIS server or a code-signing cert from a vendor. You launch certmgr.msc or the IIS Manager import wizard, pick the PFX or CER file, and boom: 0X80093101 ASN1 internal encode or decode error. The install fails immediately. No retry helps.

The culprit here is almost always a certificate that was exported with the wrong encoding, or the file got corrupted in transit. I've seen this most often with PFX files generated by older Java keytool versions (pre-8u191) or when someone e-mailed a .cer file through Outlook which mangled the base64 line breaks.

Root cause in plain English

ASN.1 is the binary language certificates speak. The Windows crypto library (Crypt32.dll) expects a specific byte structure when it reads a certificate file. When it hits 0X80093101, it means the ASN.1 parser choked on a tag or length byte that doesn't match the spec. Think of it like reading a foreign language where every 5th word is gibberish — the grammar is broken.

Most times this happens because:

• The file is encoded as base64 but saved with a .cer extension (Windows expects DER binary).
• The file has extra whitespace or line breaks at the start/end (common from copy-paste).
• It's a PKCS#7 (.p7b) file renamed to .pfx — completely different format.
• Corruption from FTP ascii mode transfer instead of binary.

The fix — re-export the certificate properly

Skip trying to repair the file. The only reliable fix is to go back to the source and re-export with the correct settings. Here's the step-by-step.

Step 1: Verify the original certificate source

If you have access to the original certificate request or the issuing CA, re-download the cert directly. If it's from a third-party CA like DigiCert or Let's Encrypt, grab the fresh copy from their portal. Don't bother with hex editors — you'll waste time.

Step 2: Re-export from the correct application

If the certificate is already installed somewhere (like a working server), export it again. Use the Certificates MMC snap-in:

1. Run certlm.msc (local machine) or certmgr.msc (current user).
2. Find the cert under Personal > Certificates.
3. Right-click > All Tasks > Export.
4. Critical: Choose "Yes, export the private key" if it's a PFX that needs the key. For just the public cert, choose "DER encoded binary X.509 (.cer)".
5. If exporting as PFX, uncheck "Include all certificates in the certification path if possible" — that's a PKCS#7 artifact that sometimes triggers the ASN1 error on import.
6. Set a password. Use something simple like Temp123! — you can change it later.

Step 3: Convert using OpenSSL as a fallback

If you can't access the original cert, use OpenSSL to re-encode the file properly. Save your broken cert as broken.pem (even if it's binary, name it .pem). Then run:

openssl x509 -in broken.pem -inform PEM -out fixed.cer -outform DER

For a PFX with private key:

openssl pkcs12 -in broken.pfx -out temp.pem -nodes
openssl pkcs12 -export -in temp.pem -out fixed.pfx

The second command re-encodes the private key and cert with a clean ASN.1 structure. I've fixed dozens of 0X80093101 errors this way.

Step 4: Import the fixed file

Now import the newly exported file. Use the same tool that failed before (certmgr.msc, IIS Manager, or certutil -importpfx). It should install without errors.

certutil -importpfx fixed.pfx

If you still get the error, the source certificate itself is damaged. Request a new one from the CA.

What to check if it still fails

Three things:

1. File extension mismatch. Check the actual bytes. Open the file in Notepad. If you see -----BEGIN CERTIFICATE----- but the extension is .cer, that's a base64 file pretending to be binary. Rename to .pem or convert with OpenSSL as above.
2. Intermediate chain corruption. Some CAs send the cert chain as a PKCS#7 file. If you try to import that as a PFX, you'll get ASN1 errors. Use certutil -dump to see what you're actually dealing with:

certutil -dump broken.pfx

If it shows PKCS7 in the output instead of PKCS12, you've got a chain-only file. You need the actual PFX with private key.

3. Windows updates. Rare, but I've seen this on Server 2012 R2 missing KB2919355. Apply latest Windows updates, reboot, try again.

One last thing: if you're importing a certificate from a USB drive or network share, copy it to the local desktop first. Network file permissions or antivirus scanning can corrupt the file mid-import. Sounds basic, but it catches people every week.