CRYPT_E_REVOCATION_OFFLINE — the revocation function could not check revocation

An internal AD CS certificate. The most common cause by far is simply an expired CRL.

1. On the failing machine, read what the certificate says its CDP is, and test it.

   Command PromptCopy

   certutil -URL C:\path\to\cert.cer

   The URL Retrieval Tool tests every CDP and OCSP URL in the chain and shows exactly which one fails, which saves guessing.

2. On the CA, check when the CRL expires.

   Command PromptCopy

   certutil -getreg CA\CRLPeriodcertutil -getreg CA\CRLPeriodUnitscertutil -CRL

3. Publish a fresh CRL.

   Command PromptCopy

   certutil -CRL

4. Copy it to every location listed as a CDP — an HTTP path is the one that matters for non-domain clients.

5. Verify the chain now builds on the failing machine.

   Command PromptCopy

   certutil -verify -urlfetch C:\path\to\cert.cer

A public certificate on a server behind a proxy or with no outbound access.

1. Check the WinHTTP proxy, which is what system services use — it is not the same as the Internet Options proxy.

   Command PromptCopy

   netsh winhttp show proxy

2. Set it if the server needs one.

   Command PromptCopy

   netsh winhttp set proxy proxy-server="http://proxy.example.local:8080" bypass-list="*.example.local;<local>"

   Revocation checks are made by the system, not by a signed-in user, so a per-user proxy configuration does nothing for them.

3. Allow the CRL and OCSP hostnames through the firewall on TCP 80. They are plain HTTP by design — CRLs are signed, so they do not need TLS.

   Blocking outbound 80 while allowing 443 is a common policy that breaks revocation checking specifically.

4. Clear the cached CRLs and retest.

   Command PromptCopy

   certutil -urlcache CRL deletecertutil -urlcache OCSP deletecertutil -verify -urlfetch C:\path\to\cert.cer