The revoking list has been released and I think about 2 million certificates have been revoked. Many of the URLs in this list of domain names have had their certificates invalidated by revocation. However, on the other hand, it seems that there are still URLs that we able to access by HTTPS connections.
So, and this domain name is on the revoking list. Pay attention to the serial. It is a match. (NOTE: ag is a command like grep.)
$ ag status.mamisrv.ne.jp tls-alpn-01-affected-certs-by-regID.csv
1660723:111808547,"04cb226a7dbd61e67e0aa166efacdd91fa68","2022-03-04T00:45:01Z","status.mamisrv.ne.jp"
I think the reason why you can access this URL is because OCSP is running. When I check the OCSP Response Data, the certificate information of the same serial is returned.
$ openssl s_client -connect status.mamisrv.ne.jp:https -servername status.mamisrv.ne.jp -CApath /etc/ssl/certs -status < /dev/null 2> /dev/null | ag Serial
Serial Number: 04CB226A7DBD61E67E0AA166EFACDD91FA68
Here's a question. Is this URL safe? Is it dangerous?
I would like to know your opinion on this situation.
When ISRG/LetsEncrypt revoked certificates, they did 2 things:
Mark the certificates as revoked and publish it as revoked into the CRL/OCSP infrastructures
Publish a CSV list/tool of those affected certificates
It's up to web browsers and client libraries to check if a certificate is revoked, and decide how to handle it.
Depending on the browser you use, those revoked certificates may or may not show up as revoked. In the past, some browsers (like Chrome) have still shown green padlocks on revoked certificates. That has been referred to as a "hard fail / soft fail" problem by some.
OCSP stapling also implements caching on the server and client level; IIRC, either can respect the cached value for up to 7 days from the timestamped signature.
TLDR; There are well known delays in how the global Certificate Revocation infrastructures handle and process revoked certificates. This is not unique to LetsEncrypt, but how the modern internet operates.
@jvanasco So that's how OCSP Stapling was supposed to be treated. Does this mean that 7 days after Jan 29, i.e. on Feb 5, the cache will expire and I won't be able to access it?
I understand now what the nature of the problem is. Thank you very much for your answer.
WARNING: no nonce in response
Response verify OK
cert.pem: revoked
This Update: Jan 31 12:00:00 2022 GMT
Next Update: Feb 7 11:59:58 2022 GMT
Revocation Time: Jan 29 00:09:04 2022 GMT
osiris@erazer tmp $
I thought OCSP responses should be updated earlier than just before the expiration? In my head I thought you´d usually update it half way the validated time frame?
I haven't looked at the RFC or Caddy's source code regarding OCSP Stapling (this domain seems to be on caddy), however every server implements stapling differently (if at all) and IMHO this feature has been somewhat experimental and "learn as we go" by every project that implements it.
As someone who develops on the server level, I would definitely try to enjoy as much time on a cache like this, and ignore the "should" timeline in favor of the "must" timeline.
FYI, I found this article from Cloudflare that goes into their implementation (at least at the time it was written). They eventually decided to pre-fetch and cache OCSP staples to avoid congestion and potential hard-fail issues. Emphasis added to this quote:
When a response started getting close to expiration, we’d fetch a new one. If the OCSP request fails, we put it into a queue to re-fetch at a later time. Since most OCSP staples are valid for around 7 days, there is a lot of flexibility in term of refreshing expiring responses.
"Close to expiration" is a, well, not very hard definition
The Baseline Requirements do have some to say about the lifetime:
4.9.10 On‑line revocation checking requirements
(...)
4. For OCSP responses with validity intervals greater than or equal to sixteen hours,
then the CA SHALL update the information provided via an Online Certificate
Status Protocol at least eight hours prior to the nextUpdate, and no later than four
days after the thisUpdate.
Yep, the Baseline Requirements place requirements on how often a CA must make a new OCSP response available (every 4 days, for OCSP responses that are valid for 7 days). But a webserver that downloads the OCSP response and then staples that response to all of their TLS handshakes can continue stapling the same OCSP response for 7 days, and that's perfectly acceptable. It's completely up to the webserver implementation how often they check for a new OCSP response to staple (with the caveat that if they wait too long, they'll be stapling a no-longer-valid response).
Most Web servers' OCSP stapling implementations will not serve an invalid (revoked) response. Instead, they'll serve what they already have, even if it's stale.
Most Web servers aren't able to trigger a renewal themselves. Even if they recognize the certificate is no longer valid, they don't have an ACME client (or an integration to one) built in.
It looks like that site is using Caddy, which can recognize an invalid response and renew. Maybe the site is running an older version without that ability, or something is wrong that's preventing validation.
But we can still access the URL in question. This makes it seem like it is possible to continue using revoked certificates. Am I misunderstanding something?
$ TZ=GMT date
Thu Feb 3 15:35:15 GMT 2022
$ openssl s_client -connect 'www.sea-mew.jp:https' -servername 'www.sea-mew.jp' -CApath /etc/ssl/certs -status < /dev/null 2> /dev/null | head -n 19
CONNECTED(00000003)
OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = US, O = Let's Encrypt, CN = R3
Produced At: Jan 27 14:22:00 2022 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 48DAC9A0FB2BD32D4FF0DE68D2F567B735F9B3C4
Issuer Key Hash: 142EB317B75856CBAE500940E61FAF9D8B14C2C6
Serial Number: 0327DE233A59025180811F2B05114C3E62A7
Cert Status: good
This Update: Jan 27 14:00:00 2022 GMT
Next Update: Feb 3 13:59:58 2022 GMT
$ ag www\.sea-mew\.jp tls-alpn-01-affected-certs-by-regID.csv
275393:49720356,"0327de233a59025180811f2b05114c3e62a7","2022-03-16T01:22:10Z","www.sea-mew.jp"
My questions are as follows.
(Q1) Why can I access to https://www.sea-mew.jp/ as of 3pm on Feb 3 (GMT)? Is (f) the reason?
(Q2) If (Q1) is correct, then why can't I access to https://sea-mew.jp/ ...? What is the difference between sea-mew.jp and www.sea-mew.jp regarding OCSP or certification?
(Q3) Why are some URLs still we can access after revoking the certificate, and was there no way for Let's Encrypt to make them inaccessible? Is the OCSP Stapling mechanism vulnerable to the certificate revoke process?
I would appreciate it if you could answer my question.
In the process of researching these on my own, I found the following past thread.
On first glance, while the domains are related they are on two different certificates.
That inherently means:
Even though they are part of the same revocation batch, they will have been revoked independently of each other, and at different timestamps.
Their will each have a different cached OCSP response.
If you compare the date in that response to the one in your posts above, the OCSP responses were cached on different days.
It is NOT the role of LetsEncrypt, or any CA, to make a web server accessible or inaccessible. That is not how the internet works.
The role of a CA is to provide a trusted validation that a website operator is the valid owner of a SSL certificate at a given point in time. This is done by the initial challenge, a timely expiry, and methods for revocation (initiated by the website owner or the CA itself). The OCSP framework provides a mechanism for web servers, and clients, to perform a lightweight check to see if the Certificate has been invalidated before the actual expiry date.
While this check against the revocation list could be done in real time for every request, doing so would absolutely cripple the operations of both the CA and the web client. A consortium of operators from Certificate Authorities, Browsers, Operating Systems, SSL client libraries publicly developed the RFCs and CA/B Forum Guidelines that agreed on the OCSP framework as a functional compromise to the certificate revocation problem -- along with all the other implementation details. With regards to Certificate Revocation, the current system is not as secure as theoretically possible - but it is as secure as practically possible.
Browsers/Libraries and Servers deal with certificate revocation differently, as do Website operators. Both a webserver and browser have a variety of means to attempt a "hard fail" scenario if there is an issue with certificates, including having a "must-staple" flag in the certificate which requires a valid OCSP staple. Not every webserver is capable of handling this, and not every browser respects it. While many website operators want a "hard fail" scenario, for a variety of reasons a "soft fail" scenario is often necessary. One example of this is when there are issues with obtaining/renewing an OCSP staple for a valid certificate due to upstream availability or network congestion.
With all that being said, the answers to your questions above depend heavily on (1) decisions the website operator has made [certificate options, web server options, security policies] and (2) decisions the website consumer has made [browser, operating system, client/library options, etc]. The role of the CA is simply to be a trusted third party that can say "this certificate was valid at this timestamp" via the original certificate or shorter-lifespan OCSP response. The domain owner is free to publish a security policy, via "must staple" flags, CAA records, server flags, etc. Ultimately, the browser/client-library is responsible for deciding what to do with all that information and how it should respect a revoked or potentially-revoked certificate.
Yes, I know that the certificate and the OCSP Response are different. However, they are the same in that they both use certificates from the revoking list and are OCSP Responses that are past the Next Update. Nevertheless, I wanted to know the reason for the different access results.
about (Q3)
I have not focused on Let's Encrypt's liability. I am not convinced that it is possible to make a site work permanently by exploiting OCSP Stapling, even though it is a revoked certificate. I simply want to know the answer to (Q1) and (Q2), and I wondered if OCSP Stapling is a beneficial mechanism for us.
