Everything You Need to Know About OCSP, OCSP Stapling & OCSP Must-Staple
What happens when a hacker gets an SSL certificate’s private key? The CA revokes it. But how does the browser know whether a website’s certificate has been revoked? OCSP is one way your web client can check…
Before an end user’s browser connects to a website via HTTPS, it needs to know that the site is using a valid SSL/TLS certificate. But how can their client or your web server verify whether a server’s SSL/TLS certificate is valid and hasn’t been revoked for one reason or another? There are two main types of certificate revocation status checks that are used by certificate authorities (CAs) — certificate revocation lists (CRLs) and the online certificate status protocol, or OCSP. Of course, there are various enhancements to both of these revocation status check mechanisms. Unfortunately, we can’t cover all of them, so we’ll just touch on a select few in this article.
But what exactly is OCSP? How does it differ from certificate revocation lists (CRLs), OCSP stapling, and OCSP must-staple? What role does the OCSP protocol play in verifying a certificate’s revocation status? And where do we go from here to improve the revocation checking process?
Let’s hash it out.
What Is the Online Certificate Status Protocol?
The online certificate status protocol is an internet protocol that’s described in the Internet Engineering Task Force’s (IETF) RFC 6960. It’s one method that web clients (browsers) use to determine the revocation status of a web server’s X.509 digital certificate when attempting to connect to a website. So, basically, the OCSP protocol is a real-time check of a website certificate’s revocation status. It’s an alternative to using CRLs.
What’s the Role of an OCSP Responder?
To put it simply: OCSP responder = OCSP server. People frequently use the terms “OCSP servers” and “OCSP responders” interchangeably because of their functions. An OCSP server belongs to the CA who issued the digital certificate. It uses the certificate’s serial number, which the client provides in its OCSP request, to look up its revocation status and “respond” with the status. (Hence its other name “OCSP responder.”)
Commercial digital certificates, which includes SSL/TLS website security certificates, are issued by trusted third parties known as certificate authorities to identify and authenticate individuals, organizations, or other entities. So, when a CA revokes a certificate, it means that they’re saying that the certificate is no longer valid for one reason or another and that it can’t be trusted. However, the CA needs a way to communicate that certificate invalidation info to users’ clients and to web servers.
This is where certificate revocation lists (CRLS) and the open certificate status protocol come into play.
Manage Digital Certificates like a Boss
14 Certificate Management Best Practices to keep your organization running, secure and fully-compliant.
Where the OCSP Protocol Fits Into the Website Security and Authentication Process
Basically, OCSP is one of the ways to check the revocation status of an SSL/TLS certificate.
When your browser tries to connect to a website’s server, it engages in a process that’s known as an SSL/TLS handshake. Most websites still rely on the TLS 1.2 handshake, but the TLS 1.3-supporting platforms are starting to increase little by little.
As part of the TLS handshake process, there are back-and-forth communications (roundtrips) that take place between the client and the web server. TLS 1.2, the older version of the protocol, has two roundtrips whereas TLS 1.3 only has one.
The purpose of these handshakes is to authenticate the server and to establish a secure, encrypted connection between the two parties. Part of this process involves the web server passing along its SSL/TLS certificate to the end user’s web browser.
But how do you know whether the certificate that it’s passing along is valid or has been revoked? That’s where certificate revocation checks (such as OCSP) come into play. But not all browsers use online certificate status protocol by default — or they use their own versions of certificate revocation checking mechanisms that curate CRL lists from CAs. For example, Mozilla Firefox and Google Chrome disabled OCSP checking by default (although Firefox still includes it as an option in its settings (see the screenshot above). We’ll speak more to that shortly.
Now that we know what leads to the certificate revocation check, let’s roll up our sleeves and dive right into the nitty-gritty of how OCSP works.
How Your Client Checks a Certificate’s Revocation Status Using OCSP
Let’s break down of the certificate revocation status check works using the online certificate status protocol to provide more clarity:
- A website’s server sends its SSL/TLS digital certificate to the client. This information contains information about the individual or organization that’s signed off by a trusted third-party CA.
- The client sends an OCSP request to a CA for verification of the certificate’s status. This request info includes the certificate’s serial number.
- The OCSP responder uses this number to check the status of the certificate. It then responds to the client with one of three answers:
- Good,
- Revoked, or
- Unknown.
- Once the client receives the answer, it can either allow or reject the session. An issue, though, comes into play when browsers have “soft fail” policies (more on that shortly).
The Online Certificate Status Protocol Is Just One Way to Check a Cert’s Revocation Status
Okay, let’s back up for a moment. There are two main ways to check the revocation status of a digital certificate — CRLs and OCSP. But there are also enhancements or alternatives to those two methods:
- Centralized CRL data like CRLSets and CRLite (previously OneCRL),
- OCSP stapling, and
- OCSP must staple.
So, what’s the difference between these different mechanisms or enhancements? CRLs and OCSP first two place the responsibility for the certificate revocation status check on the client, whereas OCSP stapling (and OCSP must-staple) places the responsibility on the website’ web server.
Let’s briefly cover each of these processes to better understand how they relate and differ.
1. Traditional Certificate Revocation Lists (and Alternatives like CRLSets and CRLite)
Checking the certificate revocation status of a certificate using a traditional CA certificate revocation list involves the web client reaching out to the CA and downloading a copy of their CRL. This is a resource-intensive process that slows down the user’s web client and makes for a kind of crappy user experience.
We don’t want to rehash all of the specifics of CRLs in this article. (It would take way too much time and that’s not why you’re here anyhow.) So, here’s a quick overview of how a CRL-based cert revocation check works:
For a deep-dive on what CA certificate revocation lists are and how they work, check out our other article.
CRLSets and CRLite
We did mention earlier, though, that some browsers have created their own curated CRL data sets from CA CRLs. For example, Google created their own mechanism (CRLSets) for non-EV SSL/TLS certificates. According to an article from ZDNet:
“Google decided in 2012 to default Chrome not to check for certificate revocation on non-EV certificates. […] Instead, Google uses their Chrome update mechanism to send batches of serial numbers of revoked certificates which it constantly gathers by crawling Certificate Authorities.”
Firefox also launched OneCRL in 2015 (their version of The Chromium Project’s CRLSets for Google) but now relies on CRLite as of December 2019. However, it’s also interesting to note that Firefox doesn’t automatically check the revocation status of certificates of short-lived certificates (those that have a validity period of fewer than 10 days).
2. Online Certificate Status Protocol
Okay, so we’ve already touched on the online certificate status protocol. Again, this process of verifying a certificate’s revocation status overcomes the main issues of CRLs and provides a real-time update. Instead of having to perform massive searches of the entire CRL for every request, the client can check the status of a single cert by using its serial number.
However, OCSP isn’t perfect (though, really, what technology or protocol is?). It still requires the client reaching out to a CA about the certificate status. As such, this process:
- Keeps the client responsible for checking the revocation status of a cert,
- Involves an inordinate number of requests to the OCSP responder (in this case, the CA),
- Requests can time out or fail, leading to those soft failures we mentioned earlier, and
- CAs still receive information about the users’ browsing histories, IP addresses, and other information that they’d likely prefer to keep private.
An issue with the OCSP responses that the servers provide is that browsers are programmed to respond in different ways. So, even if a browser receives a response saying that the status of the certificate is unknown, rather than terminating the session (what’s known as a hard fail), it may accept the certificate anyhow and enable the connection (aka a soft fail).
As far as I’m concerned, a soft fail policy somewhat defeats the purpose of checking the CRL in the first place. If a browser is going to allow a connection anyhow, why bother with the certificate check in the first place?
But enough about soft- and hard-fail policies — let’s talk about the third method of checking a certificate’s revocation status.
3. OCSP Stapling
Much like the previous status-checking method, OCSP stapling is a process that uses the online certificate status protocol. However, it’s a more advanced way of doing so. Instead of relying on the client to perform certificate revocation status checks, it places that responsibility on the web server instead.
How OCSP Stapling Works
- The web server sends regular, automatic OCSP requests to the OCSP responder (CA). This “nudge,” if you will, by the server happens as frequently as every few hours (depending on its settings).
- The OCSP responder provides time-stamped data. In response to the request, the OCSP responder sends a timestamped and CA-signed approval message back to the web server.
- The web server caches this timestamped response. It uses this cached record for reference until it receives a new update from the OCSP server.
- The web server sends the cached, CA-signed and timestamped data to the client. Whenever a client attempts to connect to a web server, the server can “staple” the timestamped OCSP response when it sends the SSL/TLS certificate to the client during the SSL/TLS handshake. The client trusts this response because it’s digitally signed and timestamped.
Just Say No to Client-Based Revocation Checks: Why OCSP Stapling Is the Better Option
With OCSP stapling, the web server frequently communicates with the OCSP responder to stay up to date with the most current certificate revocation status information. It keeps a timestamped record (cache) of the OCSP server’s responses on hand that it can pull from in the event that the responder becomes unavailable. This reduces the load on the client and proves a better user experience. It also helps them feel more confident that your site is legitimate and is run by your brand.
While you could use a certificate revocation list, as you now know, that process has its limitations. For one, those lists don’t always download frequently to the client — and they’re sometimes massive. Second, using CRLs puts the responsibility on your end users’ clients instead of your web server. And that just makes for a bad user experience all the way around.
Overall, OCSP stapling is great and is certainly a vast improvement over CRLs. But what if the client doesn’t know if the server in question supports OCSP? This is an issue that continues to plague OCSP stapling.
Enter OCSP Must-Staple
See, OCSP must-staple shippers? We haven’t forgotten you.
If you’ve heard about OCSP stapling, then it’s likely that you’ve also heard of “OCSP must-staple” (or OCSP must staple). But if not, this term let me take a sec to explain. This term refers to a certificate extension that gives the client a heads up that it should expect to receive an OCSP staple whenever it receives an SSL/TLS certificate. The goal is to shore up the certificate revocation process.
The Asia Pacific Network Information Centre (APNIC) published a great article on OCSP Must-Staple at the end of 2019. In it, they provide data about how many of the leading web clients actually support OCSP stapling and OCSP must-staple:
The Advantages (and Drawbacks) of OCSP Must-Staple
While OCSP must-staple is great in that it helps overcome some of the shortcomings of OCSP, frankly, it’s a bit testy. For it to work, all parties (the CA, client and the website’s server) must be available and performing well. Another issue is that not all major websites support the certificate extension just yet.
According to the APNIC article:
We first observed that all browsers do solicit stapled OCSP responses, indicating that they do support OCSP Stapling. However, we observed that only Firefox (on all desktops OSes and on Android) displays a certificate error to the user if a stapled OCSP response is not included with a certificate that includes the OCSP Must-Staple extension; all other browsers (including Firefox on iOS) simply accept the certificate and do not even send their own OCSP request to the OCSP responder.
These results indicate that clients are largely not yet ready for OCSP Must-Staple. However, it does appear that all clients already support OCSP Stapling, meaning the additional coding work necessary to support OCSP Must-Staple is likely not too significant.”
All of this is to say that while OCSP must-staple is a great ideal, it’s not perfect or a sure thing quite yet. There’s still more work to be done, and it’s definitely something to strive toward. We’d love to see more sites implementing it in the future — and, preferably, sooner rather than later.
Our friends at Venafi have a great article on how to implement OCSP Must-Staple if you’d like to learn more and want to implement it on your site.
Final Thoughts on OCSP, OCSP Stapling & OCSP Must-Staple for Cert Revocation Checks
We hope that this article has been informative and provides clarity about:
- What the online certificate status protocol and OCSP stapling are and how they work,
- The roles they play in website security,
- How and why OCSP stapling provides your end users with a better (and more secure) experience, and
- Where we still have room to improve as an industry in terms of adopting OCSP must-staple.
As an organization, we know that you want to provide the best (and most secure) experience possible to your site visitors and customers. And rather than “passing the buck” by making your end users’ browsers responsible for checking your site’s revocation status, we hope you’ll take the initiative by providing that information up front by implementing OCSP stapling (or, moreover, OCSP must-staple).
OCSP stapling is a great way to streamline the authentication process of the SSL/TLS handshake. This reduces the load and gets users on your site more quickly. But it’s not perfect. That’s why we hope to see more people taking their certificate revocation checking methods to the next level with OCSP must-staple.
*** This is a Security Bloggers Network syndicated blog from Hashed Out by The SSL Store™ authored by Casey Crane. Read the original post at: https://www.thesslstore.com/blog/ocsp-ocsp-stapling-ocsp-must-staple/
