Fix CRYPT_E_VERIFY_USAGE_OFFLINE (0x80092029) Error

Quick answer: Run certutil -urlcache * delete as admin, then certutil -CRL to force update CRLs. If still broken, disable revocation checking via Group Policy or registry.

Why you're seeing this error

This isn't a random glitch — it's Windows refusing to trust a digitally signed file or driver because it can't check the certificate's revocation status online. The error code 0x80092029 translates to "CRYPT_E_VERIFY_USAGE_OFFLINE," which means the server hosting the Certificate Revocation List (CRL) or Authority Information Access (AIA) was unreachable. Happens all the time on machines that are air-gapped, behind strict firewalls, or when the issuing CA's servers are down.

Had a client last month whose whole development environment locked up because Visual Studio couldn't validate a NuGet package signature — same error. The fix was simple once we tracked down the root cause.

Step-by-step fix

Check if the server is truly offline. Test connectivity to the URL in the certificate's CRL distribution points. Use certutil -URL <certificate.cer> to see which URLs it's trying to reach. If your machine simply can't get out, skip to step 3.
Force update the CRL cache. Open an elevated command prompt and run these commands:
```
certutil -urlcache * delete
certutil -CRL
```
The first clears cached CRLs, the second downloads fresh ones. If it hangs, you're offline — move on.
Disable revocation checking. This is your nuclear option. In Group Policy (gpedit.msc), go to Computer Configuration > Windows Settings > Security Settings > Public Key Policies. Double-click "Certificate Path Validation Settings," then the Revocation tab, and uncheck "Revocation check when the server is offline." Or via registry:
```
reg add "HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates" /v DisableCRLCheck /t REG_DWORD /d 1 /f
```
Reboot after.
For code signing errors (e.g., Authenticode): Set reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v WinTrustPolicy /t REG_DWORD /d 1 /f. This tells Windows to trust locally signed files even if revocation check fails.

Alternative fixes if the main one fails

Manually download and install the CRL. Find the CRL URL in the certificate details, download it via a browser on a connected machine, then import it using certutil -addstore CA crl.der.
Switch to a different certificate. If you control the signing, get a certificate from a CA whose CRL servers are more reliable — or issue your own internal CA that doesn't publish CRLs to the internet.
Use group policy to bypass for specific applications. Set Software Restriction Policies to skip revocation checks for trusted publishers.
Check for proxy or firewall blocks. CRL and AIA URLs often go to HTTP (not HTTPS) — some firewalls block those thinking they're malware. Whitelist the specific domains.

Prevention tips

If you're in an environment that routinely goes offline, pre-deploy CRLs via script. I wrote a PowerShell job that runs weekly on domain controllers to pull down all CRLs and push them out via Group Policy. Haven't seen 0x80092029 since. Also, avoid certificates from CAs with flaky infrastructure — stick to ones with solid uptime or use an internal PKI if you're on a closed network.

One more thing: never disable revocation checking on machines that touch the internet unless you really know what you're doing — it's a security hole. For isolated systems, it's fine.