OSS_TOO_LONG (0X80093010) — OSS ASN encoding error fix

The 0X80093010 error — OSS_TOO_LONG — is one of those cryptic ASN.1 decoder errors that makes you think you've corrupted your certificate. You haven't. What's actually happening here is that the OSS (Open System Software) ASN.1 parser inside Windows has hit a length limit. The structure you're feeding it — usually a certificate, PKCS#7 blob, or an OCSP response — contains a field that exceeds the parser's expected maximum.

I've seen this most often when trying to import a certificate chain where one of the intermediate CA certificates has an unusually long subject or issuer field. Real-world example: a customer was using a third-party CA that stuffed a full corporate address (like 200+ characters) into the Organization (O) attribute. The parser choked.

Below are the three most common causes and their fixes. Start with cause #1 — most users stop there.

Cause #1: Oversized certificate fields in the import or chain

The Windows CryptoAPI (CAPI2) uses an older OSS ASN.1 decoder that has a default maximum element length. When any single field in the ASN.1 structure — like a PrintableString or UTF8String — exceeds this limit, you get 0X80093010.

The fix: Re-export the certificate with shorter fields. You need to modify the certificate request (CSR) or use a tool to strip long attributes from the certificate before importing it on Windows.

1. Export the problematic certificate from wherever you got it (usually a PFX or PEM file).
2. Use OpenSSL to inspect the fields:
   

   openssl x509 -in cert.pem -text -noout | grep -E 'Subject:|Issuer:'

3. Look for any line that's more than about 120 characters wide. That's your culprit.
4. If you control the CA, regenerate the certificate with shorter O, OU, or CN values. If you don't control the CA, you can't fix the source — move to Cause #2.

Why this works: The OSS decoder pre-allocates a buffer based on the Length field in the ASN.1 TLV triplet. If the actual content is longer than what fits, it aborts. Truncating the field to under ~100 characters avoids the bug entirely. Microsoft has never officially documented the exact limit, but in practice, I've seen failures with fields >130 bytes.

Cause #2: Certificate chain is too deep or has large nested structures

Sometimes the error isn't about a single field — it's about the entire Certificate structure being too long when you try to build or validate a chain. This happens in IIS or AD CS (Active Directory Certificate Services) when the chain includes a root that's too large (some roots have huge Subject fields).

The fix: Use a smaller intermediate CA, or manually rebuild the chain without the oversized root.

1. Identify which certificate in the chain is too large:
   

   openssl x509 -in rootCA.cer -text -noout | wc -c

   
   Anything over 8000 bytes total is suspicious.
2. If the root is the problem, remove it from the chain when importing. Windows doesn't need the root to validate — it has its own trusted root store.
3. Export the chain as a PKCS#7 file without the root:
   

   openssl crl2pkcs7 -nocrl -certfile chain_only.pem -outform DER -out chain_noroot.p7b

4. Import the .p7b file into the Intermediate Certification Authorities store instead of Personal.

Why this works: The OSS decoder has to parse the entire blob before it can hand it off to the validation engine. Larger blobs increase the chance that some internal offset calculation overflows. Cutting out the root reduces the overall ASN.1 structure length, and Windows can still build the chain via its own root store.

Cause #3: Registry tweak to increase the OSS memory limit (advanced)

If you can't modify the certificates and the error persists, there's an undocumented registry value that changes the internal memory allocation limit for the OSS ASN.1 decoder. I've used this exactly twice in production — it's a last resort.

Important: This affects all ASN.1 parsing on the machine. If you set it wrong, you can crash crypto operations.

1. Open regedit as Administrator.
2. Navigate to:
   

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\

3. Create a new DWORD (32-bit) value named MaxElementSize.
4. Set it to 1024 (decimal).
5. Reboot the machine.

Why this works: The MaxElementSize key overrides the default element-size check inside ossDecode(). By raising it to 1024 bytes, you're telling the decoder to accept fields up to that length. The default was 256 in Windows 2000-era builds, and some systems still inherit that.

Side effect: Memory usage for certificate parsing goes up slightly. Don't go above 4096 — you'll invite heap corruption if a malformed cert is parsed.

Quick-reference summary

If none of these work, the next step is to capture a certutil -dump of the failing certificate and look for Tag values that say OCTET STRING with unusual lengths. Send that to Microsoft support — you've found a genuine parser bug.