Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
myfirstnameispaul opened this issue Nov 12, 2024 · 3 comments
Open

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

myfirstnameispaul opened this issue Nov 12, 2024 · 3 comments

Comments

@myfirstnameispaul
Copy link
Contributor

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

@downtownallday
Copy link
Contributor

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
Copy link
Contributor Author

I know it is configured in nginx because I see it when I run tests at Qualys:

ssl_stapling on;
ssl_stapling_verify on;

@downtownallday
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants