That depends on the client and how it interprets the response. Some could be beneficial, some can be detrimental.
I haven't seen any difference in access results. Both domains show up as revoked and expired to me on my browsers and tools. Perhaps your access differences were due to clock drift, or trusting an expired certificate. You might also be getting confused by this part of the OCSP response, which is irrelevant to the access:
...
Cert Status: good
This Update: Jan 27 14:00:00 2022 GMT
Next Update: Feb 3 13:59:58 2022 GMT
...
If you look at more lines from the debug output, you'll eventually see:
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.
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
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.
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.
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.
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.
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/".
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.
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.
