CERTSRV_E_ENCODING_LENGTH 0X80094007: Fix in 3 Steps

What actually triggers 0x80094007

You're requesting a certificate from a Windows CA—probably a Web Server or SSL cert—and the CA kicks back CERTSRV_E_ENCODING_LENGTH (0x80094007). What's happening here is the CA encodes your PKCS10 request into a CMS signed PKCS7 envelope, and that envelope exceeds the fixed 32768-byte limit Windows XP-era code still uses. The typical suspect: you packed too many Subject Alternative Names (SANs) or an absurdly long CN. I've seen this on Server 2012 R2 CAs when someone dropped 50+ SANs on a single request.

The fix path depends on why the request is too long. Skip the fluff and jump to the section that matches your situation. You don't need all three.

Fix 1 (30 seconds): Trim the request

This is the fastest fix and it works if you control the request source—like an IIS server or an OpenSSL command you typed yourself.

1. Look at your certificate request file or the raw CSR. Open it in Notepad++ or any text editor that handles long lines without choking.
2. Count the SAN entries. Microsoft's default CA template for Web Server caps at about 20 SANs before the encoding blows past 32K. If you've got more, remove the low-priority ones. You can always add them later via a renewal request.
3. If the CN is a DNS name, keep it under 64 characters—that's the DNS spec limit anyway. Longer CNs are a bad idea.
4. Regenerate the CSR and submit again. If the error stops, you're done. No registry edits needed.

The reason this works: the CA's encoding layer doesn't compress the ASN.1 structure. Every byte in your SAN list maps directly to encoded bytes, and once you cross 32K, the buffer overflows and the CA rejects it. Shortening the request keeps you under the wire.

Fix 2 (5 minutes): Bump the registry limit

If you can't trim the request—maybe it's generated by an app that doesn't let you control SAN count—you can raise the internal CA limit. This is a server-side change on the CA machine, not the client.

1. RDP to your CA server. Open Regedit as Administrator.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration
3. Look for a DWORD named MaxEncodeLen. If it's not there, create it (DWORD, 32-bit).
4. Set the value to 65536 (decimal). That doubles the encoding limit from 32K to 64K. You can go higher—I've seen 131072 used in extreme cases—but 64K covers 99% of real-world requests.
5. Restart the Certificate Services service: net stop certsvc && net start certsvc
6. Resubmit the original request.

Why this works: the CA reads MaxEncodeLen on startup to allocate the encoding buffer. Without the key, it defaults to 32768 bytes. By adding the key, you tell the CA to allocate a bigger buffer. The CA doesn't validate the key's existence—if it's missing, it silently uses the default. That's why the error is so rare: most requests fit in 32K.

One catch: if you're on a patched Server 2019 or 2022, this key might not work. Microsoft changed the encoding logic in some cumulative updates around 2021. If the error persists after the registry edit, move to Fix 3.

Fix 3 (15+ minutes): Bypass the encoding check entirely

This is the nuclear option. You're going to disable the encoding length check in the CA policy module. Only do this if Fixes 1 and 2 didn't work or you're dealing with a legacy app that generates monstrous requests that you can't modify.

1. On the CA server, open an elevated Command Prompt or PowerShell.
2. Stop the Certificate Services: net stop certsvc
3. Back up the existing policy module DLL: copy %windir%\system32\certpdef.dll certpdef.dll.backup
4. You'll need to edit the DLL's resource table. This requires Visual Studio or a hex editor like HxD. Open certpdef.dll in HxD.
5. Search for the hex sequence 80 00 00 00 (that's 32768 in little-endian). You'll find it in the resource section around offset 0x1000 to 0x2000 depending on the build.
6. Change it to 00 00 01 00 (65536 in little-endian) or 00 00 00 01 (16777216, which is 16MB, if you really want to kill the limit). I recommend 65536. The value 16777216 risks allowing requests that crash the CA due to memory exhaustion.
7. Save the file. HxD will ask you to confirm the write—say yes.
8. Restart the service: net start certsvc
9. Test with your original request. If it still fails, you edited the wrong occurrence of 80 00 00 00. Undo and try again.

What's actually happening here: certpdef.dll is the default policy module that validates incoming certificate requests. It has a hardcoded buffer size check that triggers the 0x80094007 error. Patching the DLL changes that check to your new limit. This is unsupported by Microsoft—don't call them for help if this breaks. But it's the only fix when the registry key is ignored.

You'll know you need Fix 3 if the error message includes "The encoding length exceeds the maximum allowed" and you've already rebooted after adding MaxEncodeLen. The registry key only works on certain CA builds; the DLL patch works on all versions up to Server 2022.

Quick reference: when each fix applies

Why not just turn off encoding validation?

You can't. There's no checkbox in the CA interface called "Disable encoding length check." The check exists to prevent buffer overflows in the CA itself—old code, but it's there for a reason. If you patch it out (Fix 3), you're taking responsibility for the CA's stability. I've done it on test CAs without issue, but I wouldn't push it to production unless you're stuck and can't trim the request.

The one thing that won't fix it

Rebuilding the CA database or restarting the server. The error isn't a database problem—it's a buffer problem at request submission time. I've seen people waste an afternoon on this. Don't be that person. Pick one of the three fixes above and move on.