Starting May 7th, subscribers will no longer be able to request certificates with OCSP Must-Staple. We’ve identified a small group of folks still requesting these certificates and want to proactively notify them about the upcoming end of life. We’re seeking feedback in the following areas:
Line edits for clarity, accuracy, and readability
Suggestions for any additional information to include
Thanks in advance!
Subject: Let's Encrypt: Action required: Disable OCSP Must Staple by May 7th
Hello,
Action is required to keep your certificates working.
The certificates for the hostnames below (issued by the Let's Encrypt account associated with this email address) use a feature called "OCSP Must Staple." We are ending our support for that feature, along with our support for OCSP in general, and replacing them with Certificate Revocation Lists.
After May 7th, 2025, requests for certificates with "OCSP Must Staple" will fail.
To ensure your certificates continue to automatically renew, please change your ACME client configuration to not request OCSP Must Staple.
Is there any service that requires reconfiguration when switching from a certificate with a "must staple" option to a normal certificate? If the answer is yes, then I suggest to include a phrase into the e-mail about a possible service reconfiguration requirement.
It might be helpful to have a list somewhere of how to reconfigure some common ACME clients to no longer request must-staple. Maybe it doesn't need to be in this email, but I feel like this email is pointing people here in order to get help with reconfiguring their client, and I don't know where to further point them to documentation for making the change, even for certbot. I see a --must-staple in the docs, but I don't know if that implies a --no-must-staple one can use with reconfigure, or if one needs to force a new cert (with the dreaded --force!) with all the same options but just without the --must-staple, or what. And that's just certbot, let alone all the other clients that one might be using. Even if we don't want a specific documentation page on the main web site, having a wiki forum post here with instructions for common clients would be helpful.
And now that I think about it, is there any way for the email to include the name of the ACME client that they've been using from the User-Agent? I just suspect a common question beyond "how do I change my ACME client configuration" will be "What is my ACME client", as some of these could have been set up many years ago and just running along without anyone currently knowing what's running where (Yay for automation, I suppose).
Thank you for the feedback, @bruncsak and @petercooperjr. I’ll work on adding short examples for a few popular ACME clients, highlighting which options should no longer be used when requesting certificates from Let’s Encrypt.
Perhaps rephrase that to stress the motivation, without requiring a clickthrough:
AFAIK, the "must-staple" configuration is an explicit opt-in on all clients – I don't think it's possible to request a certificate with that feature without knowingly doing so. This might be the result of a subscriber having no idea what they're doing, but perhaps note that this was an explicit request at some point?
You might also want to add something like:
If your organization requires using Must Staple, you can switch to another CA that still supports it. Please be warned there are security and privacy implications to using this extension, and other CAs are in the process of deprecating it as well.
It's odd, I've never seen this on any other LE e-mails, including the "Subscriber Agreement & Ending Expiration Notification" one that came through today
I can't find any indication in the headers of why it was flagged. SPF/DKIM/DMARC all show good.
Since certificates are still going to contain an OCSP URL until May 7, is there any way to get a staging certificate without an OSCP URL prior to that date so I can test how Apache will react? I requested a staging certificate today and it still has an OSCP URL (stg-e6.o.lencr.org).
I've already reissued all my LE certificates without must-staple, but I don't want to completely disable OSCP stapling in Apache because I use both LE and GTS certificates, and I don't want to lose OSCP stapling on my GTS certificates. But I'd like to do some testing to see how Apache handles scenarios where some certificates support OSCP and others don't.
All my vhosts use 1 LE certificate and 1 GTS certificate so I don't want to disable stapling at the vhost level, but if it's only a single warning message at startup then I can probably just live with the warnings.
Also for nginx it will lead tot a non-fatal warning message on start or reload: "ssl_stapling" ignored, no OCSP responder URL in the certificate "/path/to/cert.pem"
they forgot to disable OSCP stapling on their own server before publishing their anti-stapling article
SSL_CERT OK - feistyduck.com:443, https, x509 certificate 'blog.ivanristic.com' (feistyduck.com) from 'Let's Encrypt' valid until Mar 19 00:14:25 2025 GMT (expires in 44 days) (OCSP stapling expires in 126 hours)|days_chain_elem1=44;20;15;; days_chain_elem2=768;20;15;;
The argument is against OCSP as a whole, and there's no point in disabling OCSP stapling on their server, given a certificate with (currently) an OCSP URL...
I got that same email, and it contains a request that I should report it to abuse@mandrill.com - for whatever reason I don't know.
The content of the mail looks like spam, but the headers are intact, and given that the same text is here also, it seems accurate albeit not making sense to me.
From what I understand, Certificate Revocation Lists are a PITA, and OSCP is the solution.
There is no explanation in the mail about why to get rif of it, even less how to do it.
Mandrill is the commercial vendor that sends out the emails for LetsEncrypt. For whatever reasons the message was categorized as spam by your system - likely due to content, not headers - which caused you to see that abuse address.
CRL are indeed a PITA, but OSCP has proven itself to not be a solution and presents larger problems. The article linked to above addresses much of this.
In recent years, the CAs and Browser vendors have been working on making CRL a better solution.
There is no explanation in the mail about why to get rif of it, even less how to do it.
The ways "how" are highly specific based on the ACME Client and Webserver. That is why the email sends people to this website if they think they need help.
In terms of "why", that is addressed in the the first two links in that email, as well as the first link within the first sentence of the first linked article.
).
they forgot to disable OSCP stapling on their own server before publishing their anti-stapling article