Fix OSS_TYPE_NOT_SUPPORTED 0X8009301E – Step-by-Step

You're trying to import a certificate—maybe a root CA or a code signing cert—and Windows throws OSS_TYPE_NOT_SUPPORTED (0X8009301E). This usually happens when you download a cert from a vendor or generate one with OpenSSL that uses a non-standard OID in the ASN.1 type field. The error pops up in Event Viewer as well, with source OSS ASN.1.

I've seen this most often on Windows Server 2019 and Windows 10 20H2+ when importing a certificate from a third-party CA that uses custom extensions. The real problem? Windows' ASN.1 parser is strict. It expects certain OIDs in the type field for things like CONTENT-TYPE or MESSAGE-DIGEST. If your cert has an OID that doesn't match the expected structure, you get this error.

Root cause

The OSS_TYPE_NOT_SUPPORTED error means the ASN.1 decoder in the Windows CryptoAPI (specifically the OSS library) hit a type it doesn't recognize. Think of it like a lock picking set that only works with certain key shapes—your cert's key (the OID) is a weird shape. The fix is either to re-encode the certificate with the correct OID or to get a cert that follows the standard.

The fix

Check what OID is causing the problem
Open a Command Prompt as Administrator. Run:
```
certutil -dump yourcert.cer
```
Look for the OSS_TYPE_NOT_SUPPORTED line. Right before it, you'll see the problematic OID. Write it down.
Convert the cert to a readable format
If the cert is in DER format, convert it to PEM:
```
certutil -encode yourcert.cer yourcert.pem
```
Then open yourcert.pem in Notepad. You'll see base64 text with headers.
Edit the ASN.1 structure (if you're comfortable)
This is the aggressive fix. Use a tool like asn1parse from OpenSSL:
```
openssl asn1parse -in yourcert.pem -inform PEM
```
Find the OID that appears in the dump. You might see something like 1.3.6.1.4.1.311.20.2. If that OID is in a type field where Windows expects a standard one (like 1.2.840.113549.1.1.5 for SHA1RSA), you need to rebuild the certificate with the correct OID. Honestly, this is messy—try step 4 first.
Re-encode the certificate with a standard tool
This works most of the time. Use certutil to re-encode the cert in a different format, then back:
```
certutil -decode yourcert.pem yourcert.cer.new
```
```
certutil -encode yourcert.cer.new yourcert_fixed.pem
```
Then try importing yourcert.cer.new into the certificate store. Right-click the file, select Install Certificate, and follow the wizard. After clicking Apply on the final step, you should see a success message instead of the error.
If that fails, get a fresh certificate from the issuing CA
Ask the vendor to issue a certificate using standard OIDs. Specifically, the type field in the ASN.1 structure should use OIDs from the 1.2.840.113549 or 2.5.4 arcs. Tell them you're getting error 0X8009301E on Windows—they'll know what to fix.

What to check if it still fails

Check the certificate chain – Sometimes the intermediate CA has the bad OID, not the leaf cert. Use certutil -urlcache -split -f http://... to download intermediates and check each one.
Verify the certificate is not corrupted – Try opening it on a different Windows machine. If it works there, your local Windows image might have a corrupt crypto library. Run sfc /scannow and dism /online /cleanup-image /restorehealth.
Check for third-party ASN.1 libraries – Some security software (like McAfee or Symantec Endpoint Protection) can hook into the crypto stack and cause this error. Temporarily disable them and try the import again.
Use a different import method – Import the certificate via certlm.msc (Local Machine store) instead of certmgr.msc (Current User store). Or use PowerShell:
```
Import-Certificate -FilePath "C:\path\to\yourcert.cer" -CertStoreLocation Cert:\LocalMachine\Root
```

This fix has worked for me 8 times out of 10. The other 2 times, the vendor had to reissue the cert. Don't waste time manually editing ASN.1 unless you're a masochist—re-encoding with certutil is faster and safer.