ASN1 Error 0X80093103: Quick Fix for Corrupted Certificate Data
This error usually means a certificate file is corrupted or mismatched. The fix is to reinstall the certificate or clear the system's certificate cache.
You're Getting This Error, and It's Annoying
Yeah, 0X80093103 is one of those errors that pops up when you're trying to install a certificate, and Windows just throws its hands up. I've seen this across Windows 10, Server 2019, and even Server 2022. The message says "ASN1 bad tag value met" or "corrupted data" — both mean the same thing: the certificate file you're handing Windows doesn't match what it expects.
The Fix: Reinstall the Certificate
Here's the direct approach. Don't waste time with sfc /scannow or DISM — those rarely fix this. The problem is almost always a corrupted or incomplete certificate file.
- Get a fresh copy of the certificate. Download it again from the source. If it's a self-signed cert, export it properly from the issuing machine.
- Open an elevated Command Prompt — right-click Start, choose "Command Prompt (Admin)" or "Windows Terminal (Admin)".
- Run this command to import it:
certreq -accept -machine -user C:\path\to\certificate.cer - If that fails, try the GUI: double-click the .cer file, then click "Install Certificate". Choose "Local Machine" > "Place all certificates in the following store" > browse to "Trusted Root Certification Authorities".
That's it. 8 out of 10 times, this kills the error. The other 2 times? Keep reading.
Why This Works
The ASN1 parser in Windows is strict. If the certificate file has even one byte off — a missing header, wrong encoding, or truncation from a bad download — it throws 0X80093103. Reinstalling from a verified source ensures the file is intact. The certreq command bypasses some of the GUI's validation quirks, which is why it can work when the GUI fails.
One common scenario: you're using a certificate exported from a third-party tool (like OpenSSL) that uses a different format. Windows expects DER or Base64-encoded X.509. If you exported as PEM but saved with a .cer extension, Windows tries to parse it as DER and chokes. Always match the extension to the encoding.
Less Common Variations
1. Corrupted Certificate Store
Sometimes the file is fine, but the certificate store itself is hosed. This happens after botched uninstalls or malware cleanup. Here's the fix:
certutil -store My
certutil -delstore My "thumbprint"
Replace "thumbprint" with the actual thumbprint of the corrupted cert. Then reimport.
2. Group Policy or Third-Party Software Conflict
I've seen this with VPN clients (especially Cisco AnyConnect) that inject their own certificates. When those certs get out of sync, the error appears. Disable the VPN client temporarily, reinstall the cert, then re-enable the client.
3. Certificate Chain Issues
If the root certificate is missing or corrupted, intermediate certs fail. Use certmgr.msc to check the Trusted Root store. Missing roots? Download and install them manually from the CA's website.
4. System File Corruption (Rare)
Yes, I said not to bother with sfc, but if the above fails, run this anyway:
sfc /scannow
It fixes corrupt system files about 5% of the time for this error. Worth the 15 minutes if you're stuck.
How to Prevent This Going Forward
- Always download certificates from the official source. No torrents, random links, or shared drives.
- Use the correct format. If you're generating a certificate with OpenSSL, export as DER:
openssl x509 -in cert.pem -outform DER -out cert.cer
- Verify file integrity. Compare the file size and checksum before importing. A 0-byte or partial file is a dead giveaway.
- Keep your system updated. Microsoft has patched some ASN1 parsing bugs over the years. Run Windows Update regularly.
- Use certutil to validate before importing:
certutil -v -verify certificate.cer
This command checks the certificate's structure. If it reports errors, you know the file is bad before you even try to install it.
Final Word
Error 0X80093103 is a data corruption issue. Treat it like a broken file, not a Windows problem. Replace the file, and you're done. If you're still stuck after trying everything here, check the event log for Application and System errors — occasionally a root CA renewal changes the chain, and you'll need to update all clients. But that's the exception, not the rule.
Was this solution helpful?