OSS_BAD_VERSION (0X80093007) – The ASN.1 Version Field Mismatch

1. The Most Common Cause: Corrupted or Mismatched Certificate Store Version

What's actually happening here is that Windows expects a specific version number in the ASN.1 structure of a certificate or CRL, but it gets something else. The most common trigger is when you're importing a certificate from a third-party source — an old email attachment, a backup from a different OS version, or a self-signed cert generated with outdated tools. The version field is supposed to be 0, 1, or 2 for most X.509 structures, but sometimes tools write junk there (like 127 or 255).

The real fix: Don't waste time re-importing — you need to strip and rebuild the version field. Here's the only reliable way without writing your own ASN.1 parser:

1. Open an elevated PowerShell prompt (Run as Administrator).
2. Run: certutil -dump "C:\path\to\your\certificate.cer" — this will show you the raw ASN.1 structure. Look for the version field. It'll look like Version: 2 (0x2) or some other number.
3. If the version is not 0, 1, or 2, you've found the culprit. Use OpenSSL to re-encode the certificate: openssl x509 -in badcert.cer -out goodcert.cer -inform DER -outform DER. This forces OpenSSL to write a valid version field based on the certificate data.
4. Import the regenerated certificate: certutil -addstore -user My goodcert.cer.

Why step 3 works: OpenSSL's X.509 handling is stricter about version encoding than Windows' OSS ASN.1 stack. When you re-encode, OpenSSL checks the certificate's actual features (like extensions) and writes the correct version (0 for v1, 1 for v2, 2 for v3). Windows then sees a version field that matches the rest of the structure, and the error goes away.

If you can't use OpenSSL (locked-down machine), you can try the registry workaround in fix #2 — but it's a blunt instrument.

2. Second Most Common Cause: Windows OSS ASN.1 Stack Version Mismatch After Update

This one's subtle and usually shows up after a Windows Update (KB500xxxx or KB502xxxxx) that touched crypt32.dll or cryptnet.dll. The update changes how the OSS ASN.1 parser validates the version field — suddenly, certificates that worked fine for years now throw 0X80093007. The trigger is often a PKCS#12 (PFX) file with a version 2 PrivateKeyInfo structure (which is rare but legal). Older Windows builds accepted it; newer ones are pickier.

The fix here is to tell Windows to relax its version checking via a registry key. I don't recommend this for production servers unless you fully understand the security implications — you're basically telling the parser to ignore version mismatches.

Here's the registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDecodeObject

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDecodeObject]
"DisableASNVersionCheck"=dword:00000001

To apply it:

1. Run regedit as Administrator.
2. Navigate to the path above. Create the keys if they don't exist.
3. Add a DWORD named DisableASNVersionCheck with value 1.
4. Reboot. The error should stop for all certificate operations.

What this actually does: The OSS ASN.1 decoder has a internal flag that skips the version field validation. By default it's off. Setting this registry key flips it on. The downside: if a genuinely malformed certificate gets through, you might not catch it until something breaks downstream (like a TLS handshake failing silently).

If you don't want to nuke the version check globally, you can target only PFX imports by using certutil -importPFX with the -AT flag: certutil -importPFX -AT "1.2.840.113549.1.12.10.1.2" myfile.pfx. That AT OID tells the parser which specific version of PKCS#12 to expect, skipping the generic check.

3. Third Cause: CRL or CTL with a Version 0 That Should Be Version 1

This one's rarer but specific: you're working with Certificate Revocation Lists (CRLs) or Certificate Trust Lists (CTLs) generated by a legacy CA (like a Windows 2003 CA or a non-Microsoft CA that doesn't follow the X.509 spec tightly). The OSS ASN.1 parser expects a CRL's version field to be 1 if the CRL has any extensions (like CRL Number or Issuing Distribution Point). If the CA writes version 0 but includes extensions, you get 0X80093007.

The symptom: You try to download a CRL from an AIA URL (Authority Information Access) via certutil -f -urlfetch -verify mycert.cer and it fails with 0X80093007. The event log might show a Cryptographic Services error with that code.

The fix for administrators: Reissue the CRL with the correct version. If it's a non-Windows CA, you might need to patch the CRL manually:

openssl crl -in bad.crl -out good.crl -inform DER -outform DER

Same logic as the certificate re-encode — OpenSSL normalizes the version. If you can't reissue, you can create a local policy to ignore CRL version checks (but that's dangerous for security). Better approach: use a custom base CRL with the correct version and point clients to it via Group Policy.

Why this happens on Windows specifically: Windows uses the OSS ASN.1 library (not the native Microsoft ASN.1 parser) for CRL processing. That library is stricter about version-extension correlation. Other OSes might be more lenient. The fix isn't to blame Windows — it's that the old CA was sloppy.

Quick-Reference Summary Table

If none of these work, the problem might be a corrupted system file in the OSS ASN.1 stack itself. Run sfc /scannow and dism /online /cleanup-image /restorehealth to rule that out. I've seen crypt32.dll get corrupted by aggressive antivirus scans that quarantine parts of the crypto stack. Reboot after the DISM restore, then try the certificate operation again.