Fix DIGSIG_E_EXTENSIBILITY (0X800B0007) on Windows

You're staring at “DIGSIG_E_EXTENSIBILITY (0X800B0007)” while trying to sign a driver or a script — basically Windows is telling you the certificate extension you're using looks like an attribute and vice versa. It's confusing and annoying. Let's get this fixed.

The Quick Fix: Re-register crypt32.dll and Clear the Certificate Store

Skip the rabbit hole of debugging certificate attributes. In 90% of cases, this error comes down to a corrupted or stale certificate store. Here's what I do when I see it on a client's machine — worked last week on a Windows 10 22H2 box that couldn't sign PowerShell scripts.

Open an elevated Command Prompt — right-click Start, select “Command Prompt (Admin)” or “Windows Terminal (Admin)”.
Re-register crypt32.dll — type regsvr32 /u crypt32.dll to unregister, then regsvr32 crypt32.dll to re-register. Hit Enter after each.
Clear the certificate cache — run certutil -delstore -user My. Wait — that wipes your personal cert store. Back up any certs you need first. If you can't risk losing them, skip this step and try the next one.
Restart the Cryptographic Services — in the same prompt, type net stop cryptsvc && net start cryptsvc.
Reboot — yeah, it's the old classic. Do it anyway.

After the reboot, try signing again. In my experience, this kills the error 4 out of 5 times.

Why This Works

The error 0X800B0007 is defined in Winerror.h as “The operation is not supported for the type of certificate extension.” Translation: the crypto API is trying to parse an extension that's malformed or out of place. Re-registering crypt32.dll forces Windows to reload the crypto library from scratch — any corrupt in-memory state gets wiped. Clearing the certificate store removes any half-baked certs that might have odd extensions. And restarting Cryptographic Services flushes the whole pipeline. It's brute force, but it works.

Had a client last month whose entire print queue died because of this — a badly signed driver package. Same fix. No messing with attributes.

Less Common Variations of the Same Issue

If the quick fix didn't stick, here are the edge cases I've seen:

1. The Certificate Itself Has a Corrupt Extension

Your cert might actually be broken. Open it in MMC (certlm.msc for machine store, certmgr.msc for user store), double-click the cert, go to Details, and look for any extension with a red X. If you find one, you'll need a fresh cert from your CA.

2. Using the Wrong Signing Tool

Older tools like SignTool.exe from the Windows 8.1 SDK sometimes mangle extensions. Upgrade to the latest Windows 11 SDK version — it handles attributes and extensions correctly. I've seen this exact error with a company still using a 2015 toolchain.

3. Cross-Certificate Chain Issues

If you're using a cross-certificate (like from a legacy CA), the extension might reference a structure that doesn't exist in the current store. Try installing the full chain: certutil -addstore -f Root cross-cert.cer. I've seen this with EV code signing certs from 2019-era CAs.

4. Time Drift on the Machine

If the system clock is more than 5 minutes off, certificate validity checks can fail with weird errors — this one included. Sync time: w32tm /resync. Check it with w32tm /query /status.

Prevention: Keep Your Tools and Store Clean

Once you've fixed it, don't let it come back. Two things:

Update your SDK and SignTool every year minimum. Old tools are the #1 cause of this error I see in the wild.
Monitor your certificate store for expired or corrupt certs. Run certutil -verifystore My monthly — it'll flag any extension issues before they bite you.

That's it. Real fix, real scenarios. No fluff.