0x80092013 is CRYPT_E_REVOCATION_OFFLINE — "The revocation function was unable to check
revocation because the revocation server was offline." Windows tried to fetch revocation
data (CRL or OCSP) for a certificate in the chain and every URL in the certificate's CDP/AIA
extensions failed. This breaks TLS connections, smart card logon, CA startup and more — even
when every certificate involved is valid.
0x80092013
CRYPT_E_REVOCATION_OFFLINE: revocation server was offline
What it means
Common causes
The CRL has expired and no fresh one was published — typical when an offline root CA's annual CRL publication was forgotten, or mid-migration when the old web server was switched off.
The CDP URL is only resolvable/reachable on-prem (an internal HTTP path or LDAP CDP) but validation happens from the internet or a DMZ.
The web server hosting the CRL is down, or the file was not copied to it after the CA published.
Proxy or firewall blocks outbound HTTP to the CDP host (CRL fetches are plain HTTP by design).
How to fix it
Diagnose with
certutil -verify -urlfetch cert.cer— it tests every CDP/AIA/OCSP URL in the chain and shows exactly which fetch fails.Check CRL validity: download the CRL and inspect Next Update; if expired, publish a new one on the CA (
certutil -crl) and copy it to every HTTP distribution point.During migrations, keep the old CDP URLs serving CRLs until the last certificate referencing them has expired — killing the old web server early is the classic self-inflicted outage.
Ensure CDP URLs are plain HTTP (not HTTPS) and reachable from everywhere validation happens, including internet-based clients for cloud scenarios.
Frequently asked
Why do revocation errors appear when no certificate was revoked?
Revocation checking fails 'closed' on reachability, not on revocation status: if Windows cannot download a current CRL at all, validation fails even though nothing was revoked. Fix CRL publication and reachability, not the certificates.