Key Points
- OCSP checks certificate revocation in real time but introduces privacy, performance, and reliability trade-offs.
- A CRL is a pre-published list of revoked certificates that clients download and check locally.
- OCSP stapling reduces OCSP overhead but is not supported for Wi-Fi client certificate authentication.
- Most major browsers now prefer CRLs over OCSP for performance and privacy reasons.
- For Wi-Fi and RADIUS deployments, certificate-based RADIUS servers use CRL with Delta+Base CRL for speed.
What Is OCSP (Online Certificate Status Protocol)?
OCSP stands for Online Certificate Status Protocol. It’s a protocol described in RFC 6960 that can be used to request the revocation status of a digital certificate.
In OCSP, every authentication request requires the RADIUS server to do a lookup against the PKI using HTTP. The OCSP response requires several operations on the PKI side, including digitally signing the OCSP response with a private key.. This response is then sent back to the RADIUS server and requires another cryptographic operation, which is expensive in terms of server load, to verify the response.
One solution to minimize the lookup costs is a technique called “OCSP Stapling”, in which two of the necessary requests are combined to further enhance speed. However, stapling is not supported for Wi-Fi client certificates. Furthermore, some implementations of OCSP are vulnerable to replay or man-in-the-middle attacks.
What is CRL?
CRL stands for Certificate Revocation List. It’s exactly what it sounds like – a list of revoked certificates populated by the issuing CA.
SecureW2 CRLs are pre-parsed for faster checks. The file is copied from our PKI at fixed intervals and requires a very simple public key decryption (verify signature) and a binary lookup of a serial id in a file. Essentially, we skip the slow parts of a CRL check by doing the heavy lifting in advance of the authentication event.
Even if the file grew to a few hundred MB it would still be quicker to use the CRL because we use another improved CRL technique called “Delta + Base CRL”.
In this setup, a copy of the CRL is stored locally on the RADIUS server for quick reference (the Base CRL) and updated regularly, often during off-peak times. The update request returns the Delta CRL, a much smaller list that only contains changes to the Base CRL since the last update, significantly reducing the load.
Although it’s often considered an upgrade, the reality is that a lot of popular browsers don’t even use OCSP: Google Chrome uses a CRL; Firefox uses a CRL (admittedly, with a soft check for OCSP if the CRL fails).
Some OCSP configs are just using a CRL under the hood for most operations because it tends to be faster. Ultimately, the limiting factor in checking revoked certificates is typically network latency, not CPU cycles, so CRLs are shown to perform better across distributed networks.
OCSP had the potential to replace CRL, but in its current state, it is our belief that OCSP is an inferior solution for Wi-Fi security applications.
OCSP vs CRL: Key Differences
The table below summarizes how OCSP and CRL differ across the most important dimensions for network architects and PKI administrators.
| Attribute | OCSP | |
| Definition | Real-time protocol for querying certificate revocation status from a CA-operated responder | A periodically published list of revoked certificate serial numbers signed by the issuing CA |
| How it works | Client sends a request to an OCSP responder; responder returns a signed good/revoked/unknown status | Client downloads the CRL file and checks the target certificate’s serial number against the list locally |
| Speed | Slower under load; requires a live round-trip per authentication event | Faster at scale; CRL is cached locally and checked with a binary lookup |
| Privacy | Each OCSP request reveals to the CA which certificate (and site) the user is accessing | No real-time reporting to the CA; the client checks the list locally |
| Network failure behavior | Authentication may fail or experience a soft-fail if the OCSP responder is unreachable | Cached CRL continues to function during network interruptions, up to its validity period |
| OCSP stapling support | Supported for TLS web certificates; not supported for Wi-Fi client certificates | Not applicable |
| Best for | Short-lived TLS certificates where real-time status is critical | Wi-Fi, VPN, and RADIUS deployments where speed, privacy, and offline resilience matter |
Why Browsers Are Moving Away from OCSP
The privacy problem with OCSP is straightforward: every time a browser checks a certificate, it sends the certificate’s serial number to the CA’s OCSP responder. That responder now knows which site the user is visiting, at what time, and from what IP address.
At scale, OCSP creates a detailed browsing record held by a third-party CA. Google’s decision to move Chrome to CRLSets was driven in part by this concern, alongside performance considerations.
Reliability is a second factor. An OCSP responder is a live service, and live services go down. When an OCSP responder is unreachable, browsers must choose between blocking the user (hard fail) or allowing the connection anyway (soft fail). Soft-fail behavior, which most browsers default to, means OCSP revocation checks provide limited real security value during outages.
Performance at scale is the third factor. A CRL is downloaded once and cached locally. Every subsequent revocation check against that CRL is a local binary lookup, not a network round-trip. Across a distributed enterprise network with hundreds of daily authentication events, the cumulative latency difference is significant. As the existing SecureW2 analysis shows, the limiting factor in revocation checking is network latency, not CPU cycles, and CRLs win on that dimension.
OCSP vs CRL for Wi-Fi and RADIUS Authentication
In the context of 802.1X authentication, the choice between OCSP and CRL is not just a performance question; it is a practical one. OCSP stapling, which would otherwise reduce the per-authentication round-trip cost, is not supported for Wi-Fi client certificates. That removes the main performance mitigation that makes OCSP viable for web TLS.
RADIUS servers handling certificate-based authentication need to check revocation status for every device that connects. With OCSP, that means a live HTTP lookup against the PKI for each event.
With CRL and the Delta+Base CRL technique described above, the heavy cryptographic work is done in advance. The Base CRL is stored locally on the RADIUS server, and only the smaller Delta CRL is fetched during off-peak update cycles. The result is a revocation check that is both faster and more resilient to network interruptions than OCSP.
For organizations running a Dynamic PKI at scale, this matters even more. A managed PKI that issues certificates to thousands of devices generates a high volume of daily authentications. The per-event overhead of OCSP lookups compounds quickly, while the CRL-based approach keeps authentication latency flat regardless of certificate volume.
Schedule a demo to see how SecureW2 JoinNow Cloud RADIUS uses certificate-based authentication with optimized CRL checking for Wi-Fi and VPN deployments.
Frequently Asked Questions
What is OCSP and how does it work?
OCSP (Online Certificate Status Protocol) is a real-time protocol defined in RFC 6960 for checking whether a digital certificate has been revoked. A client sends a request containing the certificate’s serial number to an OCSP responder operated by the issuing CA. The responder returns a signed response indicating the certificate’s status: good, revoked, or unknown. Unlike CRL, which is downloaded and cached locally, OCSP requires a live network connection for each check.
What is a Certificate Revocation List (CRL)?
A Certificate Revocation List (CRL) is a file published by a Certificate Authority (CA) that lists the serial numbers of all certificates the CA has revoked before their natural expiration. Clients download the CRL and check it locally whenever they need to verify a certificate’s revocation status. CRLs are signed by the issuing CA so their authenticity can be verified without a live connection to the CA.
What is the difference between OCSP and CRL?
OCSP checks revocation status in real time by querying a live CA-operated responder, while CRL provides a periodically updated list that clients download and check locally. OCSP introduces per-authentication network latency and privacy trade-offs; CRL trades absolute real-time accuracy for speed, resilience, and privacy. For most enterprise Wi-Fi and RADIUS deployments, CRL with Delta+Base updates performs better than OCSP.
What is OCSP stapling?
OCSP stapling is a TLS extension that allows a web server to obtain and cache a signed OCSP response from the CA, then attach (“staple”) it to the TLS handshake for the client. This eliminates the client’s need to contact the OCSP responder directly, improving both performance and privacy. However, OCSP stapling applies only to web server TLS certificates. It is not supported for Wi-Fi client certificates used in 802.1X authentication.
Why are browsers shifting away from OCSP?
Browsers are moving away from OCSP primarily because of privacy concerns, reliability issues, and performance at scale. OCSP lookups disclose user browsing activity to third-party CAs. OCSP responder outages lead to soft-fail behavior that provides little real security value. And local CRL checks are faster than live OCSP round-trips at enterprise scale. Google Chrome, for example, uses its own CRL distribution mechanism (CRLSets) rather than relying on OCSP.
What are the disadvantages of OCSP?
The main disadvantages of OCSP include per-request latency from live network lookups; privacy exposure because the CA learns which certificates clients are checking; availability risk when OCSP responders go offline; and lack of support for stapling in Wi-Fi client certificate contexts. In soft-fail mode, OCSP outages mean revocation checks are silently bypassed, which undermines the security value the protocol is intended to provide.
