Certificate Revocation Fails: Which Host Cannot Reach What

Certificates can sit inside their validity window while the VPN still reports an authentication failure, and someone concludes the certificate is revoked. Those are three different facts. Revocation data has to be fetched by the device doing the validation, from a publication endpoint named inside the certificate itself. When that device cannot reach the endpoint, the check fails for reasons unrelated to the certificate's status.

The validator owns the retrieval path

Start by identifying the validator. When a laptop checks the gateway's certificate, the laptop performs the retrieval; when the gateway checks a client certificate, the gateway does it. A back-end authentication service can add a third validator with its own network position. Each has a different route to the internet and a different proxy configuration. Evidence gathered on an administrator's workstation says nothing about a server inside a DMZ.

Write down the certificate, the validator, the attempt time and the exact status code before changing anything.

Read the publication endpoint from the certificate

The certificate names where its status lives. Read those fields instead of guessing a CA address.

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

The first extension lists CRL distribution points, and the second lists authority information access methods, which can cover OCSP status and issuer-certificate retrieval. Those are different mechanisms, and an OCSP responder is not a CRL file. The publication host is often a plain web server rather than the CA machine, because an offline issuer can sign a CRL that another server distributes. A firewall rule described as access to the CA is therefore too vague to implement or review.

Test retrieval from the device that validates

Run the retrieval test in the environment that actually performs validation, with approved certificate material and no private keys.

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

The certutil run verifies the chain and reports which URL fetches succeeded or failed, while the curl call tests one publication address from the same host and returns only a status code. A failed fetch from a reachable address points at content or signature problems; a connection error points at routing, DNS or proxy. Keep both results, because one successful fetch does not prove the whole chain is usable. Change the example host and path to the distribution point found in the certificate.

Separate missing data from revoked status

Four outcomes look similar from outside: the endpoint is unreachable, the list is stale, the list is signed by the wrong issuer, or the certificate really is revoked. Only the last one is a status result, and only that one justifies removing access. Caching complicates the picture further, since previously fetched data can hide a broken publication path until the next refresh. Disabling revocation checking, deleting unrelated certificates or rebooting the gateway all substitute activity for a diagnosis.

After the fix, force a fresh authentication and confirm that the intended status retrieval succeeds. Where a controlled test identity exists, confirm it is still rejected, because availability that removes the check is not a repair.