Fix CRYPT_E_REVOCATION_OFFLINE 0x80092013 in 3 Steps

Why you're seeing 0x80092013

What's actually happening here is Windows is trying to verify a digital certificate's revocation status. Every cert has a URL baked in that points to a Certificate Revocation List (CRL) server. When your machine can't reach that URL — corporate proxy blocking it, DNS failure, the server is down, or you're on a restricted network — Windows throws 0x80092013 and refuses to trust the cert. That's by design. Windows would rather fail closed than accept a possibly-revoked cert.

This pops up in all sorts of places: Outlook can't connect to Exchange, Windows Update fails, a VPN client won't authenticate, or an install shuts down with a generic "The revocation function was unable to check revocation." I've also seen it during git pull when someone sets http.sslVerify=true on a machine with broken CRL access.

The fixes below go from quickest to most invasive. Stop when the error disappears.

Step 1 — 30 seconds: Flush the CRL cache

Windows caches revocation lists locally. If a previous check partially succeeded and cached a bad entry, you'll keep getting the offline error even when the network is fine. Clearing the cache forces a fresh download.

1. Press Win + R, type certmgr.msc, hit Enter.
2. Expand Intermediate Certification Authorities → Certificate Revocation Lists.
3. Right-click each entry and choose Delete. Don't worry, they regenerate automatically.
4. Also clear the Trusted Root Certification Authorities → Certificate Revocation Lists folder. Same deal.

Then reboot or just rerun the operation that failed. If it's still broken, move to Step 2.

Step 2 — 5 minutes: Fix the registry to allow offline checks

The registry has a policy that controls whether Windows can use cached CRLs when the server is unreachable. By default, it's set to fail the operation. You can flip it to rely on the last cached version instead.

Open Regedit as admin and navigate to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\CertificateRevocation

If the CertificateRevocation key doesn't exist, create it. Then add a DWORD called AllowOffline and set the value to 1.

Reboot. The reason this works is that Windows now treats a stale but valid CRL as acceptable instead of throwing the error. It's a pragmatic fix for environments where the CRL server is flaky but you still need to get work done.

Security folks might squawk, but the risk is minimal — you're only accepting the last known good revocation state, not skipping checks entirely. Still, if you're on a high-security network, don't do this. Fix the network instead.

Step 3 — 15+ minutes: Clear the system-wide CRL cache and force an online check

If the registry tweak didn't help, the problem is deeper. Your machine might have a corrupt CRL cache that's being reused even after reboot. The system-wide cache lives under %SystemRoot%\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content and MetaData folders.

Here's how to nuke it properly:

1. Open an elevated Command Prompt (Run as Administrator).
2. Stop the Cryptographic Services: net stop cryptsvc
3. Delete the cache folders:

del /q "C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content\*"
del /q "C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData\*"

4. Restart the service: net start cryptsvc
5. Now force a fresh revocation check with this PowerShell command:

Get-ChildItem -Path Cert:\CurrentUser\My -Recurse | ForEach-Object { if ($_.HasPrivateKey) { $_.Verify() } }

This re-verifies every cert in your personal store, which triggers a new CRL download. If any of those URLs are unreachable, you'll see the error again — that tells you it's a network issue, not a cache issue.

If you're still stuck, the next thing to do is check if your proxy is stripping HTTPS traffic. Run certutil -urlcache * delete to clear URL cache entries, then test with certutil -urlcache retrieve on the exact CRL URL from the cert. That's a deeper rabbit hole, but at least you'll know where the break is.

When to blame your network instead

All three steps assume the CRL server is reachable in principle. But if you're on a corporate VPN or firewall that blocks outbound HTTP (CRLs are often plain HTTP, not HTTPS), none of these fixes will help permanently. You'll need to either whitelist the CRL domains in your proxy or switch to a CRL that's accessible internally.

Find the CRL URL from the failing cert with certutil -verify -urlfetch cert.cer or by double-clicking the cert in certmgr.msc and looking at the CRL Distribution Points under Details. Then ping or curl that URL. If it times out, that's your real problem.

One more thing: if this happens right after you updated Windows, check for a KB patch that changed revocation behavior. Microsoft tightened this in some updates, and rolling back or installing the next cumulative update often sorts it.