Fix CRYPT_E_NOT_IN_REVOCATION_DATABASE (0x80092014)

Seen when Windows can't verify a cert's revocation status. Usually a mismatched CRL or offline OCSP. Fix by updating CRLs or switching to online checker.

You're in the middle of a remote desktop session or trying to sign into a domain-joined machine with a smart card, and boom—Windows throws CRYPT_E_NOT_IN_REVOCATION_DATABASE (0x80092014). The certificate is not in the revocation server's database. It's cryptic, and it usually pops up right when you least expect it, like during a client demo or an after-hours server update. I've seen this exact error on Windows Server 2016 and 2019 boxes after a CA certificate was renewed but the old CRL distribution point went stale.

What's Actually Happening

Every time Windows verifies a certificate, it checks to see if that cert has been revoked. It does this by looking at a Certificate Revocation List (CRL) or hitting an Online Certificate Status Protocol (OCSP) responder. The error means the revocation server responded, but the specific certificate's serial number wasn't on the list. That doesn't mean the cert is bad—it means the server's database doesn't have an entry for it. Could be the cert was never issued by that CA, or the CRL is outdated and hasn't been refreshed with new entries.

Root cause is almost always one of two things:

The CRL file is old and missing entries for recently issued certs.
The certificate being validated is using a revocation URL that points to the wrong CA or a test CA.

Fix It in 5 Steps

Update the CRL. On the CA server (usually your domain controller), open Command Prompt as admin and run certutil -crl. That forces a fresh CRL publication. Wait a few minutes if you have delta CRLs enabled.
Clear the cached CRL on the client. On the machine throwing the error, run certutil -urlcache * delete to flush the local CRL cache. Then retry the operation.
Check the CDP on the certificate. Right-click the cert in the Certificates MMC, go to Details, and look at the 'CRL Distribution Points' field. Make sure the URL is reachable. If it's an LDAP path, try hitting it in a browser—if it 404s, your CRL publishing is broken.
Switch to Online Checking. If you're in a non-domain environment or you're sick of CRL headaches, open Internet Options → Advanced tab → Security section, and uncheck 'Check for server certificate revocation'. Yes, it's a band-aid, but if the cert is trusted and you're just hitting a test box, it gets you moving.
Re-enroll the certificate if the one you have was issued by a test CA or an old CA that no longer exists. Use certreq -enroll or the Certificates MMC to request a fresh one from the production CA.

If It Still Fails

You've done the steps and you're still staring at 0x80092014. Here's what I check next:

Is the time off? If the client's clock is skewed by more than a few minutes, the revocation check will fail. Sync with w32tm /resync.
Is the CA server reachable? Ping the OCSP responder or CRL URL. I had a client whose firewall was blocking HTTP to the CA, so the CRL check timed out and threw this error.
Check the event log. Look at System and Application logs for event IDs 70 or 71 from CertSvc. They'll tell you if the CA failed to publish the CRL.

In one memorable case, the client's CA had been restored from a backup and the CRL delta list was corrupt. Rebuilding the CA from scratch was the only fix—but that's rare. For 99% of you, updating the CRL and clearing the cache does it. Skip the deep rabbit hole until you've tried that.