Fix CRYPT_E_NO_REVOCATION_CHECK 0X80092012 in Windows

Yeah, this error is annoying. You're trying to install software, open a program, or connect to a service, and Windows throws up CRYPT_E_NO_REVOCATION_CHECK (0x80092012). It means the system couldn't verify the certificate's revocation status — basically, it can't tell if the certificate has been revoked. The good news: you can fix this in under three minutes.

The Fast Fix: Disable Revocation Checking Temporarily

This is the quickest way to get past the error. It's not a permanent solution — you'll want to re-enable this later — but it gets things moving.

1. Open the Run dialog by pressing Windows Key + R.
2. Type inetcpl.cpl and press Enter. The Internet Properties window pops up.
3. Click the Advanced tab at the top right.
4. Scroll down to the Security section. You'll see a checkbox labeled Check for publisher's certificate revocation — uncheck it.
5. Below that, find Check for server certificate revocation — uncheck that too.
6. Click Apply, then OK.
7. Restart the browser or application that gave you the error. Try again.

After you uncheck those boxes, you should see the error go away. If it doesn't, close all browsers and try once more. This works for Internet Explorer, Edge, and any app that uses the Windows certificate store — which is most of them.

Wait — what if you're not using a browser?

This fix also applies to standalone programs like Windows Update, Microsoft Office, or .NET applications. The Internet Properties control panel controls the system-wide certificate revocation behavior. You don't need to open a browser for the change to take effect.

Why This Works

Here's the deal: Windows tries to check every certificate against a Certificate Revocation List (CRL) published by the issuing Certificate Authority (CA). When your computer can't reach that CRL — maybe the CA's server is down, your internet is spotty, or the CRL URL is malformed — Windows throws the 0x80092012 error. By disabling revocation checking, you're telling Windows "skip that check, I trust this certificate."

This isn't something you want to leave off forever. It's a diagnostic measure. If the error only happens on certain networks or with specific software, you'll want to dig deeper — but for getting unblocked right now, this works.

Less Common Variations of This Issue

Sometimes the checkbox fix doesn't stick. Here are a few other scenarios I've seen in the field.

Group Policy overrides your settings

If you're on a company laptop or a domain-joined machine, your IT department might have locked those settings via Group Policy. You'll see the checkboxes grayed out or reset themselves after a reboot. In that case, you need admin rights to change the policy or ask your IT team to whitelist the certificate.

Corrupted certificate store

If disabling revocation checking doesn't work at all, the certificate store itself might be corrupt. You can rebuild it:

1. Open an elevated Command Prompt — right-click Start, choose Command Prompt (Admin) or Windows Terminal (Admin).
2. Type certutil -store Root and press Enter. This lists all root certificates. If you see errors or missing entries, the store is damaged.
3. Run certutil -generateSSTFromWU roots.sst to download a fresh set of root certificates from Windows Update.
4. Then import them: certutil -addstore Root roots.sst.

This forces Windows to rebuild its trusted root list. After this, re-enable revocation checking and try again.

Proxy or firewall blocking CRL access

Some corporate proxies or security software block outbound connections to CRL URLs. You can test this by temporarily disabling the firewall or proxy. If the error disappears, you know the blocker is the culprit. Whitelist the following URLs:

• crl.globalsign.com
• crl.microsoft.com
• ocsp.digicert.com
• Any URL listed in the certificate's CRL Distribution Points extension

You can view those URLs by double-clicking the certificate in the error dialog, going to the Details tab, and looking for CRL Distribution Points.

Prevention: Don't Let This Happen Again

The best long-term fix is to make sure your system can always reach CRLs. Here's a checklist:

• Keep Windows Update running. Microsoft regularly updates the list of trusted root certificates through Windows Update.
• Run the Microsoft Root Certificate Updater manually from time to time. It's free from Microsoft's download center.
• If you're on a corporate network, make sure your proxy doesn't block ocsp and crl domains. Most CAs publish their CRLs at predictable URLs.
• Don't disable revocation checking permanently. Only use it as a temporary workaround. Leaving it off lets you install revoked certificates, which is a security risk.
• Use a tool like Sigcheck from Sysinternals to check certificate chains before installing software. It'll tell you if revocation checks would fail.

One more thing: if you see this error only with a specific piece of software, contact the vendor. Their certificate might genuinely be revoked or misconfigured. It's not always your system's fault.