EAP-TLS Revocation Failures After Segmentation
A hospital uses FortiAuthenticator 6.5 as the RADIUS server for 802.1X on 4,000 clinical devices. Authentication is EAP-TLS with certificates issued by a Microsoft CA through SCEP. FAC has certificate revocation checking enabled, and the CDP in issued certificates is http://pki.hospital.local/crl. After a network segmentation project, FAC can reach LDAP and DNS but not the CRL HTTP URL. Clinicians report EAP-TLS failures; some devices receive certificate revoked even though their certificates are valid. FAC authentication logs show CRL download failed, and a pilot shows authentication succeeds when CRL checking is disabled. OCSP is not configured. The FAC server certificate is valid, and the CA chain is installed. No device certificates were reissued. The CRL is 18 MB and published weekly. An OCSP responder exists but is not allowed through the firewall.
1. Diagnose the failure and explain why disabling CRL checking is not the right production fix.
Read the worked answer
The segmentation change broke the CRL distribution point path, so FAC cannot download the CRL. With revocation checking enabled and no cached CRL, the RADIUS EAP-TLS decision fails; some clients may be reported as revoked because the revocation status cannot be confirmed. Disabling CRL checking makes the pilot succeed but removes the control that blocks stolen or retired device certificates, so it is not a production fix. Confirm with a packet capture or curl from the FAC CLI to the CDP URL, check the FAC authentication log for CRL download failed, and verify DNS and firewall policy. If the CRL cannot be reached, configure a reachable OCSP responder or a reachable CRL mirror, then re-enable checking and test both a valid and a revoked certificate.
2. Compare CRL and OCSP options for this deployment and recommend a target configuration.
Read the worked answer
CRL is simpler but the 18 MB weekly file creates bandwidth and cache-timing issues; OCSP gives per-certificate status but adds a network dependency and privacy considerations. For 4,000 clinical devices, prefer OCSP if the responder can be made highly available and reachable from FAC, with CRL as fallback. Allow the FAC to reach the OCSP responder over HTTP or HTTPS, configure the responder URL in the certificate profile or FAC revocation settings, and test timeout behavior. If OCSP is not allowed, publish the CRL on an internal HTTPS mirror reachable from FAC and shorten the CRL interval only if operationally justified. Do not disable revocation checking globally; scope any exception to a pilot.
3. What verification and monitoring would prove the fix before closing the incident?
Read the worked answer
Validate from the FAC CLI with a direct request to the CRL or OCSP URL, then run a RADIUS EAP-TLS authentication for a known-good device and a known-revoked test certificate. Check FAC logs for revocation result, not just success. Capture packets on the FAC interface to confirm the request leaves and the response returns. Add monitoring for CRL age, OCSP response time, and download failures; alert before the next weekly CRL expires. After the fix, keep the pilot exception disabled and document the firewall rules and DNS names. Repeat the test after any network segmentation change.