Fix CERT_E_REVOKED (0X800B010C) When a Certificate Is Explicitly Revoked

You're staring at CERT_E_REVOKED (0X800B010C) and wondering why a certificate that was working yesterday suddenly isn't. Yeah, that's annoying. But here's the thing: this error doesn't mean the cert expired. It means the issuer explicitly revoked it. That's a deliberate action, not a time-based one. Let's fix it.

The Fix That Works Most of the Time

First, update the Certificate Revocation List (CRL) on the machine throwing the error. Windows caches CRLs, and if the cached copy is stale, you'll get a false positive revocation. Here's how:

1. Open an elevated Command Prompt (right-click → Run as administrator).
2. Run certutil -urlcache * delete to clear the entire URL cache, including CRLs.
3. Then run gpupdate /force to refresh group policy, which often triggers a fresh CRL download.
4. Restart the application or service that was failing. If it's a browser, close it completely and reopen.

If that doesn't work, the revocation might be real. Check the certificate's revocation status directly:

certutil -verify -urlfetch MyCert.cer

Replace MyCert.cer with the actual certificate file. This forces a live CRL check and tells you if the cert is genuinely revoked or if it's a cache issue. If it says revoked, you're dealing with a real revocation.

Why This Works

What's actually happening here is that Windows caches CRLs to speed up subsequent checks. When a cert is checked, the system looks at the cached CRL first. If that CRL is older than the next update time specified by the CA, it's supposed to fetch a fresh one—but sometimes that fails silently, leaving you with outdated revocation info. Clearing the cache forces a fresh download. The -urlfetch flag in certutil does the same thing but also shows you the details so you can see exactly what's happening.

Less Common Variations

Sometimes the fix isn't cache-related. Here are a few scenarios you might hit:

The CA's CRL Endpoint Is Unreachable

If your machine can't reach the CRL distribution point (check the certificate's CDP extension), Windows will fail the check with a revocation error—even if the cert is actually valid. In that case, the fix is networking, not cert management. Make sure the URL in the CDP extension is resolvable and reachable. You can test it with curl -I http://crl.example.com/root.crl.

Time Skew on the Machine

If your system clock is off by more than a few minutes, revocation checks will fail. Revocation is time-sensitive. Fix the clock via w32tm /resync or the Date & Time settings, and re-test.

Third-Party Security Software Interfering

Some EDR or antivirus products intercept CRL checks and block them, thinking they're malicious. If you see the error only in one specific app but not others, temporarily disable the security software and re-test. If that fixes it, add an exception for the CRL URL.

Prevention

You can't prevent a genuine revocation—the issuer controls that. But you can prevent the cache-related false positives that cause this error to pop up out of nowhere.

• Make sure your system time is synced automatically. Use w32tm /query /status to verify.
• Keep Windows updated; Microsoft regularly patches CRL handling bugs that cause phantom revocations.
• If you control the CA, keep your CRL lifetime short (e.g., 24 hours) and publish frequently. This minimizes the window where a revoked cert still looks valid, and also reduces the chance of stale cache issues.
• For internal CAs, consider using OCSP instead of CRLs—OCSP is real-time and avoids the caching problem entirely. But that's a bigger change, so only do it if you have control over the PKI infrastructure.

Remember, CERT_E_REVOKED isn't a bug. It's the system doing its job. The trick is figuring out whether the revocation is legit or just a misread. The steps above will tell you which one you're dealing with.