Fix TRUST_E_COUNTER_SIGNER (0x80096003) Invalid Counter Signature

You're staring at 0x80096003 and it's blocking something you need

I get it. This error pops up when Windows tries to verify a signed file and finds that the counter signature — that extra signature from a timestamp authority — doesn't check out. It's not a generic "something's wrong" error; it's specific and fixable.

The direct fix: Re-sign the file with a valid counter signature

If you control the file (like your own driver or installer), the cleanest fix is to re-sign it using SignTool.exe from the Windows SDK. Here's the command that works:

signtool sign /fd SHA256 /a /tr http://timestamp.digicert.com /td SHA256 yourfile.exe

The flags matter:
/fd SHA256 — hashes the file content with SHA256, not the deprecated SHA1.
/a — picks the best certificate from your store (you need a code signing cert installed).
/tr — specifies the RFC 3161 timestamp server. Old /t uses an older protocol that some servers dropped.
/td SHA256 — tells the timestamp server to hash the timestamp request with SHA256.

Why this works: The error means the existing counter signature is either from an untrusted source, its certificate expired, or it was countersigned with a weak hash that Windows no longer validates after a security update. By re-signing, you replace the entire signature chain with one that's current and trusted.

If you can't re-sign the file: Fix the certificate trust

Can't re-sign because it's a third-party file? Then the issue might be that the timestamp authority's root certificate isn't trusted on your system. This happens often on offline machines or after removing old root certs. Here's how to check and fix:

1. Open certmgr.msc (Certificate Manager for current user) or certlm.msc (local machine).
2. Navigate to Trusted Root Certification Authorities > Certificates.
3. Look for the timestamp authority's root — common ones are DigiCert, Sectigo, GlobalSign, Microsoft Root Authority.
4. If missing, download the root cert from the CA's website and import it into that store.

But be careful: only install roots from CAs you trust. Malware sometimes exploits this by dropping a fake root that countersigns its payloads with a stolen key to bypass your security.

Less common variations of the same issue

1. Windows Update / Microsoft Update error 0x80096003

You'll see this when Windows Update tries to install a package whose catalog file has a corrupted or revoked signature. The real trigger is often a failed previous update that left system files in a mixed state. Run DISM /Online /Cleanup-Image /RestoreHealth first, then sfc /scannow. If that doesn't help, reset the update components using the Microsoft-provided script at https://support.microsoft.com/en-us/topic/windows-update-troubleshooter.

2. Driver installation fails with code 52 (unsigned driver)

Windows 10 20H2 and later enforce SHA256 counter signatures strictly. If a driver was timestamped before 2016 with an old SHA1 timestamp, it'll fail. Solution: boot into Disable Driver Signature Enforcement only as a temporary test. Permanent fix requires getting a re-signed driver from the vendor.

3. Malware that deliberately corrupts signatures

Some malware families (like those using stolen signing certs) will strip or corrupt counter signatures on legitimate files to avoid detection. If you see this error on a system file that shouldn't be modified, run a full scan with Windows Defender Offline or Malwarebytes. The signature failure might be a red flag that the file was tampered with.

Prevention: Stop it from coming back

Three things will keep this error rare:

• Keep root certificates updated. Windows Update does this automatically, but if you manage an offline system, manually pull the latest roots from Microsoft's Certificate Trust List (CTL) every few months.
• Don't block timestamp servers. If your firewall or proxy blocks traffic to timestamp.digicert.com or similar, signatures will fail. Whitelist *.digicert.com, *.sectigo.com, and timestamp.globalsign.com.
• Use SHA256 everywhere. When signing your own code, always use SHA256 file digests and RFC 3161 timestamping. Avoid SHA1 entirely — it's been deprecated since 2016.

One more tip: if you're dealing with old signed installers from 2010–2015, many used timestamp servers that no longer exist. The only reliable fix there is to download a newer version from the vendor. Don't waste time trying to make a dead certificate chain work.