Fix OSS_INDEFINITE_NOT_SUPPORTED 0X8009300D Fast

I know this error is infuriating. You're trying to install a certificate or maybe a Windows update, and bam — 0X8009300D with that cryptic "OSS_INDEFINITE_NOT_SUPPORTED" message. It's enough to make you want to throw your laptop out the window.

Here's the deal: this error means the ASN.1 decoder in Windows hit an indefinite length encoding that it doesn't support. In plain English? The certificate or data you're feeding it is using a format trick that Windows crypt32.dll just won't accept. The fix depends on what you're doing when it hits. Let's tackle the most common causes first.

Cause 1: Importing a Certificate with Indefinite Length Encoding

This is the #1 trigger. You've got a .cer or .p7b file from a vendor, maybe for a VPN or a secure email, and Windows chokes on it. The certificate was encoded using BER (Basic Encoding Rules) with indefinite length — a legal ASN.1 technique, but Windows often expects DER (Definite Encoding Rules), which is stricter.

I've seen this happen specifically with certificates generated by older Java apps or some OpenSSL configurations. The fix? Re-encode the certificate to DER format.

Here's how to fix it:

1. Install OpenSSL if you haven't already. You can grab it from the official site or use a package manager like chocolatey (choco install openssl).
2. Open a command prompt and run this:

openssl x509 -in yourfile.cer -outform DER -out fixed.cer

That forces the output to DER, which Windows handles without complaint. If your file is in PKCS#7 format (.p7b), try this instead:

openssl pkcs7 -in yourfile.p7b -inform PEM -outform DER -out fixed.p7b

Then import the fixed.cer or fixed.p7b into the certificate store again. Works like a charm nine times out of ten.

But what if you can't get OpenSSL? Maybe you're on a locked-down corporate machine. Then you can use PowerShell to convert the certificate. This is a bit more involved but doable:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$cert.Import("C:\path\to\yourfile.cer")
$bytes = $cert.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert)
[System.IO.File]::WriteAllBytes("C:\path\to\fixed.cer", $bytes)

That's your first and most direct fix.

Cause 2: Windows Update Failing with 0x8009300D

Less common but still a regular in my support days: Windows Update (or more often, WSUS) throws this error when trying to install an update that contains a signed catalog file. The catalog's signing certificate uses indefinite length encoding, and the older crypto stack on Windows 7 or Server 2008 R2 just can't parse it.

This usually happens after Microsoft started using newer signing certs that your outdated Windows version doesn't fully understand. The fix? Make sure your OS has the latest servicing stack. For Windows 7, that means installing the SHA-2 code signing update (KB4474419) and the servicing stack update (KB4490628).

If you're getting this on Windows 10 or 11, it's often a corrupted Windows Update component. Don't bother with the DISM and SFC dance first — that's a time sink. Instead, try resetting the Windows Update cache directly:

1. Stop the Windows Update service. Open an admin command prompt and type:

net stop wuauserv

2. Then delete the cache folder contents. Don't delete the folder itself.

del /f /q %windir%\SoftwareDistribution\Download\*.*

3. Restart the service:

net start wuauserv

Then try the update again. I've seen this clear the error more often than you'd expect. The indefinite length error sometimes happens because the download got corrupted mid-transfer, leaving a half-baked catalog. Clearing the cache forces a fresh download.

Cause 3: Third-Party Software with Broken ASN.1 Parsing

Here's the sneaky one. The error might not come from Windows at all — it could be your antivirus, a PDF tool, or even an old version of Adobe Reader that uses the OSS ASN.1 library. That library is notorious for being strict about indefinite length. If you see this error in a non-Windows context (like a PDF signing or an email encryption tool), then the software's own parser is failing, not the OS.

I remember a case where a client's internal document management system threw this error whenever they tried to validate a signed PDF. The PDF was fine, but the app's ASN.1 parser was garbage. The fix wasn't in the file — it was updating the software.

So first, check what program is actually throwing the error. The message box usually says the application name. If it's a third-party app, do these:

1. Update the software to the latest version. Vendors fix ASN.1 parsing bugs all the time.
2. If it's a Java app, update the Java runtime. Older JREs had issues with indefinite length in certain contexts.
3. If you're stuck with an old version, try converting the certificate to DER as described in Cause 1, then re-import it. Sometimes feeding the app a DER-encoded cert bypasses the parser's weakness.

One more thing: if you're using a VPN client like Cisco AnyConnect or Pulse Secure, make sure the client is up to date. Those clients love to embed certificates in their configs that can trigger this error if they're stale.

And if you're a developer and you're seeing this in your own code, stop using indefinite length when you encode. Use DER. It's unambiguous and widely supported. There's no good reason to use BER indefinite length for anything Windows-related.

Quick Reference Summary

That's it. You won't need to dig into the registry or mess with crypto APIs for this one — it's almost always a format mismatch or a stale component. Try the fixes in that order, and you'll be out of the woods in no time.