What is the relationship between the revoking list and OCSP Stapling?

To narrow down @jvanasco's explanation a little bit, your understanding is correct until this point:

You would be able to access the site - using most, but not all, browsers and clients - regardless of whether or not there's a stapled OCSP response.

Mozilla Firefox is the only major Web browser that checks OCSP by default. With Google Chrome (for example), the site would remain accessible even if there were no OCSP response stapled at all. But when using a client that does check OCSP, the site will not be accessible unless a valid, current OCSP response is either stapled or available from the CA. [inaccurate, see discussion below]

OCSP stapling does help improve performance for users of Firefox and other clients that check OCSP. On the other hand, some Web servers' implementations of OCSP stapling are relatively fragile and a little bit unreliable or difficult to manage. It is usually beneficial to use OCSP stapling if you're using a Web server that handles it well, like Caddy.


If webservers refuse to serve an OCSP response with "revoked" status but instead keep sending the response with "good", even if it's already invalidated due to the "Next Update" time being in the past, well, then for that specific site it's not beneficial..

That would require the must staple extension in the end leaf certificate.


Good point, thank you! I'd forgotten when writing that sentence that almost all clients "fail open" (err on the side of permitting the connection) when there is no OCSP response available.


Indeed, unless must staple is set in the certificate, an OCSP response is not mandatory.


That's pretty much unavoidable. Lots of servers don't support ocsp stapling.

Dovecot and postfix, for starters.


Most browsers also push Certificate Revocation Lists to clients as part of updates, which can effectively invalidate the certificate before the OCSP expiry as well. This article speaks of a few browser strategies:

sidenote: ssl.com is using a root cert untrusted by a few of my machines/browsers :rofl:


Thank you all for your answers.

Yes, I had understood about must staple.

My perception is as follows.

  • If the certificate has been revoked and OCSP Stapling is not used, it cannot be accessed.
  • However, when the certificate has been revoked and OCSP Stapling is being abused, it can be accessed.

This is based on the behavior of URLs that do not use OCSP Stapling and (Q1) and (Q2) when accessed from a browser.

(I'm sorry if my explanation was not good enough and gave everyone the wrong idea.)

This is why I questioned the existence of OCSP Stapling.


How have you access these sites? I can not reproduce your situation on any of my systems or machines.


Some of them have become inaccessible over time. What happens here https://www.sea-mew.jp/ for example? At least at the moment I can access it with Firefox 96.

1 Like

This is, at least for Let's Encrypt, incorrect.

Let's Encrypt only uses OCSP to communicate revocation status of end leaf certificates. Only for the root certificate, it issues a CRL. So if OCSP is not used (by the client, webserver or combination of both), the site can be accessed indefinitely.


@Osiris Sorry, I meant when OCSP Stapling is not used, not when OCSP is not used.


That doesn't really make any difference, OCSP stapling or no stapling. Fact is, most browsers won't care about OCSP if it's not stapled, so you will be able to access the site at all times. Only Firefox (as far as I know) by default retrieves the OCSP response from the OCSP responder actively.


It is possible that I have fundamentally misunderstood the behavior of OCSP and OCSP Stapling. However, there was something unnatural about the behavior when accessing the site in a browser, so I decided to start this thread. I'll continue my research to try to explain it better.

1 Like

OCSP can be, from a clients (i.e. webbrowsers) perspective, active or passive, depending on whether the OCSP response is stapled by the webserver or not.

If there is no OCSP stapling available (or not requested by the webbrowser), then OCSP is purely an active procedure from the webbrowser: it has to actively request an OCSP status from the OCSP responder the webbrowser finds in the certificate. There are not much browsers doing this (it's considered a privacy issue, the CA can monitor OCSP requests and link visited websites to IP addresses for example). If there is no "must staple" TLS extension in the certificate and the webbrowser does not actively request an OCSP status, the website will always be accessible (from an OCSP standpoint).

If OCSP stapling is available and the webbrowser requested this in the TLS handshake when connecting to the site, even then there are multiple possibilities:

  • the webserver might serve an expired OCSP response
  • the webbrowser may be fine with that (most probably are)
  • the webserver might serve a valid OCSP response with revoked
  • and the webbrowser should deny access to the website.

Not sure what happens if the certificate includes the "must staple" and the webserver serves an expired OCSP response though.. Might be as simple as the browser thinking "I must get a stapled OCSP response, I got one, I'm all good" even if it has been expired already.


Wow! I can recreate and confirm. This helps, and now I believe I can explain after doing some digging.

I was calculating the expiry as 7 days from the "This Update" timestamp, because several RFCs and software projects mention "7 days".

After digging around a lot of Mozilla docs, wow - I was wrong. In several parts of their documentation and security information, Mozilla explicitly notes they cache the OCSP response for 10 days in accordance with the current policy defined in the CA/B Forum Baseline Requirements. I double checked the current Baseline Requirements, and confirmed. Most projects and systems are implementing a maximum cache duration of 7 days by choice, not by requirement – Mozilla has instead decided to implement the maximum cache period allowed by the Baseline Requirements of 10 days.

I tried toggling several of mozilla's security and ocsp settings in the advanced config section (about:config) but nothing influenced this behavior. There is a setting I hoped might influence this behavior, security.pki.cert_short_lifetime_in_days which is set to 10 days, but that does not influence the OCSP staple - just certificates near their own expiry.

see: CA/Revocation Checking in Firefox - MozillaWiki

Tagging @JamesLE as he was involved in this topic.


I'm Japanese and I was analyzing the status of revoked *.jp domain names.

There are currently 37 cases in the *.jp domain where the OCSP Response by OCSP Stapling says "good", but the OCSP responder says "revoked" (that is, the Next Update has expired by OCSP Stapling). However, 24 of them are revoked as expected (i.e., they cannot be accessed).

At this time, we have confirmed that there are 13 *.jp URLs that can be accessed by OCSP Stapling. One of them is the URL "https://www.sea-mew.jp/".

I hope this helps you to think about this issue.

1 Like

That is only happening with the Firefox browser. It is not happening with Chrome, Safari or Edge. Nothing right now suggests that is due to OCSP stapling. Are you in control of that domain and able to turn stapling on and off for tests?

Mozilla/Firefox would be the correct group for you to have a discussion with regarding their implementation details. I am interested in what they say, most people probably here are to.

That is simply how OCSP stapling works. The entirety of the stapled OCSP response - including the "Cert Status: good" - was generated at the "This Update" timestamp, and then digitally signed. The "Next Update" just means the CA will have an update by that timestamp at a minimum (see RFC 6960 - X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP). That date does not expire the staple, like a "notAfter" date would. According to the CA/B forum rules (https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.1.pdf) Servers and Browsers are allowed to cache the "good" status for up to 10 days.

None of your concerns are within the scope of LetsEncrypt. We're all interested in this, but your concerns are centered on how Mozilla/Firefox implements the CA/B Forum's Baseline Requirements. Everything that Mozilla/Firefox has done is in 100% accordance with the Baseline Requirements - other browsers are more aggressive on how long they cache OCSP staples.


That's right. Although the revoking list was the trigger, I think the essence of what needs to be considered is within Firefox or the browser. In addition, I may have written too much unnecessary content due to my insufficient knowledge. I apologize if any inappropriate behavior was included.


Having engaged with everyone on this forum for many years, I am certain I can speak for everyone that no apologies are necessary and there was no inappropriate behavior.

I am sorry if any of my comments came across poorly due to language issues. I tried to write as tersely as possible and avoid colloquialisms you might not understand. What you discovered is a very odd implementation detail in Firefox that caught a lot of people by surprise. I should have included Firefox in my own tests, but I did not because they generally have the best SSL implementation (they ship with their own Root Trust Store, instead of relying on the Operating System) which tends to avoid most SSL issues that other browsers experience.


Thank you all so much for your answers!

Looking back at the answers so far, especially @jvanasco 's answers, my questions (Q1) and (Q2) are now completely understood. (Q3) was an extra question for (Q1), which also made sense to me. Once I realized that, I had no more questions.

It was very useful for me. If anyone has any other information, etc., I would be happy to have anyone add a comment. There are no further questions from me. Thanks!