OSS_UNIMPLEMENTED (0x80093019) — When ASN.1 Encoders Hit a Wall

Yeah, 0x80093019 is one of those errors that shows up right when you think you've nailed the cert enrollment and then throws a wall at you. The culprit is almost always the ASN.1 encoder underneath Windows CNG refusing to serialize something it doesn't understand — most often a key that's too small, a non-standard OID, or a malformed extension in your certificate request.

The fix

Start here, in order. Skip nothing.

1. Confirm the error source. Open an elevated command prompt and check the CAPI2 operational log. This will tell you whether it's CNG, a smart card CSP, or a third-party ASN.1 library (OSS Nokalva is common in enterprise PKI).

wevtutil qe Microsoft-Windows-CAPI2/Operational /c:20 /rd:true /f:text | findstr /i "80093019 ASN"

2. Check your key size. If you're generating anything below RSA-2048, that's your problem. Windows 10 1809+, Server 2019, and every modern TPM will refuse to encode an RSA-1024 or below key into a PKCS#10 request. The OSS implementation treats those curves and key sizes as unimplemented. Regenerate the key:

certutil -csp "Microsoft Software Key Storage Provider" -key -f -len 2048 MyRequest.inf MyRequest.req

Or in PowerShell:

New-SelfSignedCertificate -KeyAlgorithm RSA -KeyLength 2048 -Subject "CN=test" -CertStoreLocation Cert:\LocalMachine\My

3. Validate the request itself. Feed the CSR through certutil to see exactly which field blows up:

certutil -dump MyRequest.req

Look for 'Unknown' or 'Unsupported' next to any extension. Nine out of ten times it's a custom extension with a malformed DER wrapper or an OID that isn't registered with the local policy module.
4. Update the OSS ASN.1 runtime. If OSS Nokalva's ASN.1/C or ASN.1/C++ DLLs are on the box (look for ossasn1.dll, asn1rt.dll), check the version. Anything below 10.x chokes on modern SHA-256 signed structures and EdDSA. Get the current redistributable from the vendor — don't try to shim an old one.
5. For smart cards, reinitialize the minidriver. Pull the cert, wipe the card with the vendor's tool, and re-enroll. Old minidrivers write ASN.1 blobs in a format modern Windows can't round-trip.

Why this actually works

The 0x80093019 code maps to OSS_UNIMPLEMENTED in the Open Systems Solutions ASN.1 library — which Microsoft licensed and embedded in portions of CNG and the legacy CSP stack. It's not a generic failure. It means the encoder got a type it doesn't have a serialize routine for. Translation: your input is outside what the library was compiled to handle.

RSA-1024 falls into that bucket because the CNG policy layer hard-blocks it before serialization even starts. Custom OIDs fall in because the encoder has no mapping table entry. Old minidrivers fall in because they emit BER where DER is required. All three trip the same return code, which is why this error is so annoying to diagnose — different root causes, same symptom.

Don't waste time on SFC /scannow or DISM. I've seen people run both three times on a machine that just had a 1024-bit key. The error is data, not corruption.

Less common variations

Code signing with an old token

SafeNet eToken 5110 and older YubiKey 4s (pre-4.3.5 firmware) will throw 0x80093019 when signtool tries to build the CMS structure. The token's firmware can't produce the signature format modern signtool expects. Firmware update or new token. There's no workaround.

FIPS mode + exotic curves

If HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy\Enabled is set to 1, brainpoolP256r1 and several other curves are rejected at the ASN.1 layer. Stick to P-256, P-384, or RSA. Turn FIPS off only if policy allows it.

SCCM / Intune certificate profiles

Configuration Manager pushes a template that references an OID your CA doesn't publish. The enrollment fails on the client with 0x80093019 and looks like a client-side problem. Check the template on the CA, not the endpoint.

Third-party VPN clients intercepting

Some older Cisco AnyConnect and Palo Alto GlobalProtect builds hook the crypto stack and inject their own ASN.1 routines. If the error only happens when the VPN is connected, that's your answer. Update the client.

Prevention

• Ban RSA-1024 and below by GPO across the domain. Windows has the policy, use it.
• Keep the OSS ASN.1 redistributable current on any server that does PKI work. Track it in your patch cycle like any other library.
• Test CSR templates in a lab CA before rolling to production. Custom OIDs especially.
• Retire smart cards older than 5 years or with firmware that hasn't been updated in 3. That hardware rots.
• Enable verbose CAPI2 logging permanently on your PKI servers. It costs a few MB of disk and saves hours of guessing.

Bottom line: 0x80093019 is a data problem, not a Windows problem. Fix the input, not the OS.