search

mail-in-a-box / mailinabox

Mail-in-a-Box helps individuals take back control of their email by defining a one-click, easy-to-deploy SMTP+everything else server: a mail server in a box.
https://mailinabox.email/
Creative Commons Zero v1.0 Universal
14.05k stars 1.44k forks source link

Let's Encrypt: Intent to End OCSP Service #2458

Open myfirstnameispaul opened 1 week ago

myfirstnameispaul commented 1 week ago

From the Let's Encrypt blog:

Jul 23, 2024 • Josh Aas

Today[sic] we are announcing our intent to end [Online Certificate Status Protocol (OCSP)](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol) support in favor of [Certificate Revocation Lists (CRLs)](https://letsencrypt.org/2022/09/07/new-life-for-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](https://cabforum.org/) passed [a ballot](https://lists.cabforum.org/pipermail/servercert-wg/2023-September/003998.html) 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](https://learn.microsoft.com/en-us/security/trusted-root/program-requirements) 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](https://community.letsencrypt.org/c/api-announcements/18) 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.

downtownallday commented 1 week ago

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.

myfirstnameispaul commented 1 week ago

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

downtownallday commented 1 week ago

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).