-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Comments
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: mailinabox/conf/nginx-ssl.conf Lines 15 to 16 in 1699ab8
|
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). |
From the Let's Encrypt blog:
Just a head's up since MiaB versions are on an, er, unscheduled release cycle.
The text was updated successfully, but these errors were encountered: