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
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.
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.
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.
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.
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!
Oops, I didn't go through this comment.
Unfortunately, the domain in question is not under my control, so I can't control OCSP Stapling.
Yes, I understand very well. Thanks.
@jvanasco I have prepared a test environment on my website by manually revoking the certificate.
- The test URLs are as follows:
- If revoked, here is the HTTP URL to view the information:
I tested with Firefox, Chrome, and iOS Safari, but I haven't been able to confirm stable and accurate results, so I haven't been able to compile a list of my results.
The rough results are as follows.
|1||Certificate issued and apache restart||Starts Web Server|
|2||Access both HTTPS URLs||Send out OCSP Stapling for the first time|
|3||Revoke the certificate and keep using the same certificate||Web Server was restarted|
|4||Access "ocsp-stapling" page||OCSP Stapling says "good" and OCSP Responder says "revoked"||can accessed||can accessed||can accessed|
|5||Access "ocsp-stapling-off" page||OCSP Staplling has no response and OCSP Responder says "revoked"||can accessed||can accessed||revoked error|
|6||A few minutes later||OSPF Stapling will no longer be sent.|
|7||Access "ocsp-stapling" page||OCSP Staplling has no response and OCSP Responder says "revoked"||can accessed||can accessed||revoked error|
|8||Access "ocsp-stapling-off" page||OCSP Staplling has no response and OCSP Responder says "revoked"||can accessed||can accessed||revoked error|
|9||A few more minutes later|
|10||Access "ocsp-stapling" page||OCSP Staplling has no response and OCSP Responder says "revoked"||revoked error||can accessed||revoked error|
|11||Access "ocsp-stapling-off" page||OCSP Staplling has no response and OCSP Responder says "revoked"||revoked error||can accessed||revoked error|
Don't trust this table. Maybe another result is correct.
Why am I can access it in my Chrome? Is this what OCSP Stapling is all about? By the way, I'd like you to take a look at https://metro.knowledgecode.jp/ . As for this URL, OCSP Stapling says "good" and OCSP Responder says "revoked". So, and when I access this URL in my Chrome, I get revoked error. Why am I cannot access it in my Chrome? refs. OCSP Checker
I was a little confused as to what the expected result was. I'll share the information so far. That's all.
If there are no restrictions on the issuance of Let's Encrypt certificates, I can try the test from Step 1 as many times as you like.
I don't see an ocsp staple in the response from either site.
metro.knowledgecode.jp. I can access it on all browsers. If you can not access it, my guess is that Google probably pushed it in a payload of revoked certificates to users in Japan but not in America.
The important things to know about this certificate and staple:
According to crt.sh, it was revoked on 2022-01-29
The stapled "good" OCSP response was generated on
This Update: Jan 28 18:00:00 2022 GMT
According to the Baseline Requirements, browsers may use the cached "good" response for 10 days - so it is valid until
Feb 07 18:00:00 2022 GMT. Browsers/Clients can choose to expire it sooner.
If you read through the article I posted earlier, How Do Browsers Handle Revoked SSL/TLS Certificates? - SSL.com , it goes through how the different browser vendors each notify their users of revocations, and concludes with a study similar to what you're doing. Everything really just varies by how the browsers operate.
The stapled "good" OCSP response just means the CA has verified the cert as valid at the exact moment of "Jan 28 18:00:00 2022 GMT". Browsers don't have to trust that response.