mail-in-a-box
Let's Encrypt: Intent to End OCSP Service
From the Let's Encrypt blog:
Jul 23, 2024 • Josh AasToday[sic] we are announcing our intent to end Online Certificate Status Protocol (OCSP) support in favor of Certificate Revocation Lists (CRLs) as soon as possible. OCSP and CRLs are both mechanisms by which CAs can communicate certificate revocation information, but CRLs have significant advantages over OCSP. Let’s Encrypt has been providing an OCSP responder since our launch nearly ten years ago. We added support for CRLs in 2022.
...
In August of 2023[sic] the CA/Browser Forum passed a ballot to make providing OCSP services optional for publicly trusted CAs like Let’s Encrypt. With one exception, Microsoft, the root programs themselves no longer require OCSP. As soon as the Microsoft Root Program also makes OCSP optional, which we are optimistic will happen within the next six to twelve months, Let’s Encrypt intends to announce a specific and rapid timeline for shutting down our OCSP services. We hope to serve our last OCSP response between three and six months after that announcement. The best way to stay apprised of updates on these plans is to subscribe to our API Announcements category on Discourse.
We recommend that anyone relying on OCSP services today start the process of ending that reliance as soon as possible...
Just a head's up since MiaB versions are on an, er, unscheduled release cycle.
Interesting, and good to know about, but wouldn't this be transparent to MiaB? I don't think there is anything to do. There aren't any TLS clients in MiaB that are doing OCSP requests that I can think of that would need changes (we configure Postfix to use DANE for verification). I would expect that Let's Encrypt will simply remove OCSP links from the server certificate during a renewal when they're ready and that will affect nothing. CRL distribution point links are already included in Let's Encrypt's intermediate CA certificates. It appears some browsers aren't even using OCSP or direct CRL downloads any more (like Google Chrome which delivers CRLs as an app update; see: https://www.ssl.com/blogs/how-do-browsers-handle-revoked-ssl-tls-certificates/). I guess if you've built something custom using the remote API, and are doing OCSP it might affect you, but that is out of MiaB's scope.
I know it is configured in nginx because I see it when I run tests at Qualys:
https://github.com/mail-in-a-box/mailinabox/blob/1699ab8c02e6813075a65fff9903c85e31d52445/conf/nginx-ssl.conf#L15-L16
You're right, nginx is performing an OCSP request for stapling. My guess is that once Let's Encrypt makes the change you might start seeing warnings in the log but the server will still function (eg. like the self-signed cert used during setup).
May be an unrelated question, but why are Let's Encrypt certificates not signed in MIAB? Let's Encrypt says they provide signed certificates and warning shouldn't be shown. I read somewhere that this is how mail clients behave but for the web (HTTPS) I have seen in the past Let's Encrypt certificates not showing the warnings in the browser.
Here's a report on those warnings showing up in the nginx logs : https://discourse.mailinabox.email/t/how-to-resolve-ssl-stapling-ignored-no-ocsp-responder-url-in-the-certificate-error/12993 There's also a solution: commenting out the related nginx configuration lines. Currently testing that
