Fix TRUST_E_TIME_STAMP (0x80096005) – Certificate Timestamp Error

Quick Answer

Set your clock to the correct date/time (including time zone), then run Windows Update to refresh the root certificate list. If that doesn't work, manually install the latest Microsoft Root Certificate Package (KB931125).

What’s Actually Happening

You're seeing TRUST_E_TIME_STAMP (0x80096005) when trying to install a signed driver, run an old installer, or update software. The error means Windows can't verify the timestamp on a digital signature. The culprit here is almost always one of two things: your system clock is wrong (the timestamp is outside the certificate's validity window), or the root CA certificate used to sign the timestamp has expired and isn't updated on your machine.

This hits hard on systems that haven't seen updates in months, or on VMs with clocks reset to factory dates. I've seen this most often with old Visual Studio builds, signed MSI files from 2019–2021, and Windows 10 1809/1909 systems that skip monthly patches.

Fix Steps

1. Fix the clock first. Don't skip this. Go to Settings > Time & Language > Date & Time. Turn off “Set time automatically,” manually set the correct date and time zone, then re-enable automatic sync. Run w32tm /resync in an admin Command Prompt to force a sync.
2. Update root certificates via Windows Update. Open Settings > Update & Security > Windows Update. Check for updates and install all pending updates, especially the “Servicing Stack Update” and “Monthly Rollup.” Reboot.
3. Manually install KB931125. If Windows Update fails or you're offline, download the Microsoft Root Certificate Package from the Microsoft Download Center. It's a .cab file. Extract it with expand -F:* rootupdate.cab c:\certs, then run certutil -addstore Root c:\certs\*.cer. Reboot again.
4. Check timestamping URL (for developers). If you're signing your own code with signtool, make sure your timestamp server URL is current. The old http://timestamp.verisign.com/scripts/timstamp.dll is dead. Use http://timestamp.digicert.com or http://timestamp.comodoca.com instead.
5. Clear the SSL certificate cache. In an admin command prompt, run certutil -urlcache * delete. This flushes stale cached certs that might be corrupt.

Alternative Fixes If the Above Fails

• Reinstall the software or driver with a newer signed version. Many vendors re-sign their binaries after CA expiries. Check their site for an updated build.
• Disable strong certificate enforcement (not recommended). For testing only, set registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\OID\EncodingType0\CertDllCreateCertificateChainEngine\Config DWORD StrongSignatureCompare to 0. This is a band-aid – revert it after testing.
• Use sysadmin rights to bypass timestamp check. If you're installing a driver, enable Test Mode (bcdedit /set testsigning on), install, then disable it (bcdedit /set testsigning off).

Prevention Tip

Keep your system clock synced to an NTP server (pool.ntp.org works) and enable automatic Windows Update. For internal network certs, make sure your CA issues timestamps that don't expire until after the signing cert does – I've seen admins set timestamps to 5 years and wonder why they fail in year 6. Also, if you're signing code, use a timestamp server that provides long-term validation (RFC 3161). This way, even if the signing cert expires, the timestamp holds up.