OSS_TABLE_MISMATCH (0x8009301D) Fix: Certificate Chain ASN Error

What triggers this error

You'll see 0x8009301D – OSS_TABLE_MISMATCH when something tries to decode an ASN.1 structure — usually a certificate, CRL, or CMS/PKCS#7 message — and the internal table lookup fails. The most common triggers:

• Installing a third-party certificate that has a malformed ASN.1 tag or length field
• Running software that builds custom PKCS#7 signatures (like legacy email clients or document signing tools)
• Windows Update failing to validate a signed catalog file — you'll see this in CBS.log or WindowsUpdate.log
• Schannel or CryptoAPI errors during TLS handshakes with servers using broken intermediate certs

I've seen this most often on Windows Server 2016 and 2019 after a bad certificate import, or on Windows 10 when a third-party VPN client installs a root CA that's incorrectly encoded.

Root cause – plain English

The OSS ASN.1 parser in Windows (used by CryptoAPI and Schannel) expects a specific mapping between ASN.1 tags and internal data types. When it encounters a tag, length, or value that doesn't match any entry in its internal table, it throws OSS_TABLE_MISMATCH.

This isn't a random crash. It means the certificate or signed data you're feeding it has a structure the parser can't handle. The culprit is almost always a certificate with a corrupted or non-standard encoding — things like:

• An INTEGER with leading zero bytes where none should exist
• A SEQUENCE with a length field that says 100 bytes but only 99 bytes follow
• A BIT STRING with a padding byte count that doesn't match the actual data

Your job is to find which certificate or signed file is causing the problem.

Fix – step by step

Step 1: Identify the bad certificate

1. Open Event Viewer, go to Windows Logs > Application or System. Filter by Event ID 36888 or 36887 (Schannel errors) or search the source for "CAPI2".
2. Look for an error entry that mentions 0x8009301D. It should show you a certificate thumbprint or serial number.
3. Open an admin PowerShell and run:
   

   Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Thumbprint -eq "THE_THUMBPRINT"}

   Replace THE_THUMBPRINT with the one from the event log.

If the event log doesn't give you a thumbprint, check %windir%\logs\CBS\CBS.log for the error. It'll appear near a line with CSI or CORRUPT.

Step 2: Remove or reinstall the bad certificate

1. If you found the cert in the Personal store, right-click it > Delete. You'll need to re-import it from a trusted source.
2. If the cert is in Trusted Root Certification Authorities or Intermediate Certification Authorities, remove it and re-download it from the CA's official site.
3. Re-import using certlm.msc (for local machine) or certmgr.msc (for current user). Don't double-click the .cer file — use the MMC snap-in to avoid encoding issues.

Step 3: Clear the CRL cache

Sometimes the error comes from a cached CRL that's got a bad ASN.1 header. Blow it away:

certutil -delstore CA ""
net stop cryptsvc && net start cryptsvc

This removes all cached CRLs from the CA store. They'll be re-downloaded on next validation.

Step 4: Check for conflicting registry entries

Some software (looking at you, legacy backup agents) injects custom OID mappings into the registry. These can trip the OSS table. Check here:

HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType0

Look for any keys that don't look like standard Microsoft ones. If you find third-party entries, export them, then delete. Reboot.

If it still fails

Don't bother with system file checker (SFC) or DISM — they almost never fix OSS_TABLE_MISMATCH. The issue is data, not system files.

Instead:

• Use Process Monitor to trace which file or registry key the failing process is touching when the error fires. Filter by Result is NAME NOT FOUND or ACCESS DENIED near the error timestamp.
• If it's a third-party app (like a VPN client or document signer), temporarily uninstall it. If the error goes away, contact their support — they need to fix their ASN.1 encoding.
• If it's Windows Update, run DISM /Online /Cleanup-Image /RestoreHealth anyway — but I'm telling you, it rarely helps. The real fix is finding and replacing the corrupted catalog file. Check %windir%\SoftwareDistribution for .cat files with recent timestamps.

One last thing: if this happens on a domain controller, check if you've got a CA certificate in NTAuth store that's been manually imported with the wrong encoding. That's bitten me twice.