OSS_PDU_MISMATCH 0X80093009: Fix in 3 Steps

You're enrolling a certificate and bam – error 0x80093009. The full message reads something like "OSS_PDU_MISMATCH: ASN.1 PDU is not compatible with the specified encoding". I've seen this on Windows Server 2016, 2019, and even 2022 CAs. The root cause is almost always a mismatch between what the client sends and what the CA expects, usually because of a stale template or a corrupted request.

Don't bother reinstalling the CA role – that's overkill 90% of the time. Work through these fixes in order. Stop when yours clears.

Fix 1: Quick Registry Tweak (30 seconds)

On the CA server, open regedit and check if this value exists:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\[YourCA Name]\

Look for a DWORD called DisableOldOSCPDUs. If it's not there, create it. Set it to 1. Then restart the Certificate Services service:

net stop certsvc && net start certsvc

Why does this work? Older OSes (Windows 7, Server 2008) sometimes send PKCS#10 requests with a different ASN.1 structure than newer CAs expect. This registry key tells the CA to ignore the legacy PDU type and parse the request more leniently. It's a known workaround from Microsoft KB 2801679.

If you get the error from a modern Windows 10/11 client, this might not help. But it's a 30-second test, so do it anyway.

Fix 2: Reissue the Certificate Template (5 minutes)

This is the fix I use most often. The template has a corrupted or outdated ASN.1 structure – often from being copied or modified in a previous CA migration.

1. On the CA, open the Certificate Templates console (certtmpl.msc).
2. Find the template you were enrolling against – it's usually the one in the error details or the one you selected in the cert request.
3. Right-click it and choose Duplicate.
4. Give the copy a new name like "NewTemplate - WebServer".
5. Adjust the permissions to allow your users or computers to enroll.
6. Close the console, then open the Certification Authority console (certsrv.msc).
7. Right-click Certificate Templates, choose New → Certificate Template to Issue, and pick your duplicated template.
8. Retry the enrollment using the new template.

Why this works: the original template may have a schema version or extension that's confusing the CA. Duplicating resets the template's internal structure while keeping most settings. I've fixed dozens of OSS_PDU_MISMATCH errors this way – it's the real fix in most cases.

If you're using auto-enrollment, you'll need to wait for Group Policy to refresh. Run gpupdate /force on the client and try again.

Fix 3: Advanced ASN.1 Debugging (15+ minutes)

If the first two fixes didn't help, the request itself is malformed. You need to capture the request and look at its structure.

First, enable CAPI2 logging on the client machine:

certutil -setreg CA\CRLFlags 0x40000000
net stop certsvc
net start certsvc

Actually, that's for the CA side. For the client, open Event Viewer, go to Applications and Services Logs → Microsoft → Windows → CAPI2, right-click Operational, and enable the log. Reproduce the error, then look for the failed certificate request event. Expand the details and look at the request's raw bytes.

Better yet, generate a request manually on the client and inspect it. Open an admin PowerShell and run:

certreq -new -inf request.inf request.req

You'll need a request.inf file with the right subject and key usage. Once you have the .req file, use OpenSSL to decode it:

openssl asn1parse -in request.req -inform PEM

Compare the output with what a known-good request looks like. The most common issue I've seen is a missing or wrong ExtensionRequest attribute – especially the CertificateTemplate OID. If the template OID doesn't match what the CA has, you'll get exactly this error.

Check the OID in the request against the CA's template OID:

certutil -v -template

Look for the template's OID, like 1.3.6.1.4.1.311.21.8. .... If it's different, that's your mismatch.

Another thing to check: the CA might have multiple templates with the same name but different OIDs after a migration. Clean up old templates that aren't in use.

If you're still stuck, enable verbose logging on the CA:

certutil -setreg CA\LogLevel 0x5
net stop certsvc
net start certsvc

Then watch %windir%\system32\certsrv\certlog for more detail. The error will be logged right before the failure.

When you've fixed the request, request a new cert with certreq -submit and confirm it goes through.

Note: If you're on a modern setup with Windows Server 2022 and clients on Windows 11, check if your CA is running in -AlternateSignatureAlgorithm mode. That can cause PDU mismatches with clients expecting the old signature format. Re-run the CA setup and clear that flag if it's enabled.

Remember – start with the registry fix, then duplicate the template. That combo solves the issue 80% of the time. Only break out OpenSSL when you're ready to get your hands dirty.