Fix CRYPT_E_NO_VERIFY_USAGE_CHECK 0X80092028 – Certificate Error

Quick answer

Run certutil -urlcache * delete as admin, then certutil -generateSSTFromWU roots.sst and import the generated SST file into Trusted Root Certification Authorities. Reboot.

This error appears when Windows fails to validate that a certificate is allowed for its specific usage (e.g., code signing, server authentication). The caller (usually an application or Windows Update) calls CertGetCertificateChain and the chain engine reports that the certificate's enhanced key usage (EKU) isn't trusted for the requested purpose. The system's root store is outdated, or the issuing CA revoked the intermediate—or the certificate itself was issued by a CA that no longer meets Microsoft's root program requirements (like old Symantec or GeoTrust certificates).

What's actually happening here is the chain engine can't find a valid certificate path that satisfies the usage check. It's not a corrupted file—it's a trust decision the OS refuses to bypass. The real fix is to force Windows to download the latest root certificates, or manually install the missing intermediate.

How to fix CRYPT_E_NO_VERIFY_USAGE_CHECK

Clear the certificate URL cache
Open an elevated Command Prompt (Win+X → Terminal (Admin)). Run:
```
certutil -urlcache * delete
```
This flushes all cached certificate revocation lists (CRLs) and intermediate certificates. The error often stems from a stale CRL that says a still-valid cert is revoked.
Download and install the latest root certificates
Run:
```
certutil -generateSSTFromWU roots.sst
```
This grabs Microsoft's current set of trusted roots from Windows Update and saves them as roots.sst. Then import it:
```
certutil -addstore Root roots.sst
```
The reason step 1 + 2 works is you're replacing the entire root store with the one Microsoft actually trusts right now—not the one that shipped with your OS build.
Force a group policy update for certificate trust (domain-joined machines only)
Run:
```
gpupdate /force
```
If your domain pushes certificate trust via GPO, this re-applies it.
Reboot
This clears any in-memory certificate caches and forces the LSA process to reload the store.

If the error persists

Check the specific application's certificate

If the error comes from a specific tool (e.g., a PowerShell script, an installer, or a VM host), find the exact certificate that's failing. Use certlm.msc (Local Machine store) or certmgr.msc (Current User) and look for certificates with red X's or expired dates. If you see one, right-click → Delete. Then reinstall the software—it should pull a fresh copy.

Reinstall the Microsoft Root Certificate Program updates

Open Settings → Windows Update → Advanced options → Optional updates. Look for a Update for Root Certificates (KB number like 931125). Install it and reboot. This is the manual way to force what step 2 did automatically.

Manually add the missing intermediate CA

If you know which CA issued the cert (say, DigiCert or GlobalSign), download the intermediate CA certificate from their official repository (typically a .cer or .crt file). Then run:

certutil -addstore CA "C:\path\to\intermediate.cer"

This puts it in the Intermediate Certification Authorities store. The chain engine will find it there before it tries the cache.

Check for a time sync issue

Certificate validation relies on accurate time. If your system clock is more than 5 minutes off, Windows will reject any cert as outside its validity period. Run w32tm /resync as admin. If that fails, check your CMOS battery.

Prevention

This error almost always comes back if you don't keep the root store updated. Enable Automatic Root Certificates Update via Group Policy (Computer Configuration → Administrative Templates → System → Internet Communication Management → Internet Communication settings → Turn off Automatic Root Certificates Update → set to Disabled). On Windows 10/11, this is on by default—but some enterprise security tools disable it. Check with your IT team if you're corporate. For personal machines, leave Windows Update enabled and run the certutil -generateSSTFromWU command quarterly. It's cheap insurance against this exact error.