You're trying to sign a driver or verify a certificate and Windows throws you DIGSIG_E_ENCODE (0X800B0005). I've seen this most often when someone's using an older signing tool like signtool.exe from the Windows 7 SDK against a certificate that's been reissued with a newer structure. It also pops up if the certificate's ASN.1 encoding is malformed — maybe the issuer's root CA used a non-standard extension or the cert chain got corrupted during export.
What's actually going on?
Windows uses ASN.1 (Abstract Syntax Notation One) to encode digital certificates and signatures. The 0X800B0005 error means the cryptographic API (crypt32.dll) hit a piece of encoded data it couldn't parse. Think of it like trying to open a PDF with a text editor — the structure's wrong. Usually it's one of three things:
- The certificate file is damaged or incomplete.
- You're using a tool that doesn't support the encoding format (e.g., old signtool with SHA-256 certs).
- The cert chain has a missing intermediate or an unreadable extension.
Fix it in 4 steps
Step 1: Use the latest signing tools
If you're still on signtool.exe from the Windows 7 SDK, that's your problem. Grab the Windows 10/11 SDK or just use the version from Visual Studio 2022. Had a client last month whose entire print queue died because of this — they were signing a print driver with a tool from 2010.
# Install Windows 10 SDK via winget
winget install Microsoft.WindowsSDK.10.0.22621.0Then use the updated signtool.exe from C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\.
Step 2: Verify the certificate file
Run this to check if the cert itself is readable:
certutil -dump yourfile.cerIf certutil chokes with ASN errors, the cert file is hosed. Export it again from the CA — make sure you include the entire chain (Base64 X.509 is safest).
Step 3: Re-encode the certificate
Sometimes just converting the format fixes the ASN structure. Open the certificate in MMC (Certificates snap-in), export it as Base-64 encoded X.509 (.CER), then import it back and export again as DER encoded binary X.509 (.CER). This strips any flaky ASN extensions the CA added.
Step 4: Sign with explicit algorithm
Force signtool to use a specific hash algorithm. I've seen 0X800B0005 vanish when you specify SHA-256 instead of letting it default to SHA-1:
signtool sign /fd SHA256 /a /f MyCertificate.pfx /p MyPassword /tr http://timestamp.digicert.com /td SHA256 MyDriver.sysStill failing? Check these
- Timestamp server: Use a known-good one like
http://timestamp.digicert.com. Some free timestamps return garbled ASN. - Intermediate certificates: The CA might have updated their chain. Re-download the latest intermediates and include them in the signing command with
/ac. - Corrupt PFX: If the PFX password includes special characters, it can corrupt the ASN during extraction. Try exporting to a password without symbols.
- Event log: Look in
Application and Services Logs/Microsoft/Windows/CAPI2/Operationalfor more details. The error message there will tell you exactly which certificate in the chain is busted.
I've seen this error take down a whole driver signing pipeline for a week because someone used an expired intermediate. The fix is almost always in the toolchain version or the cert export format. Don't overthink it — start with the latest signtool and a fresh certificate export.