In December 2024 Let's Encrypt announced their deprecation of OCSP support, and they are doing it for real: the last cron jobs are failing because of it, and forcing their users to remove OCSP.
{
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "Error finalizing order :: OCSP must-staple extension is no longer available: see Ending OCSP Support in 2025 - Let's Encrypt",
"status": 403
}
Their motivation reduces to the following:
to simplify LE's own operations: less gear to maintain;
the difficulty of implementing OCSP stapling correctly;
the claim that CAs may violate privacy.
I refuse motivation 2. Those who did not implement OCSP stapling correctly are to blame for their own problem. Those who did it correctly gained a competitive advantage. I spent time implementing OCSP stapling correctly, and hate the very idea to undo the work.
I also refuse motivation 3, because LE does not collect those data. The fact that other CAs may do it, is not a strong enough motivation to deprecate OCSP stapling. The converse is true: by not collecting data, LE has a competitive advantage over other CAs, and thus gain more users.
Their alternative to OCSP stapling is a new CRL mechanism implemented by Mozilla, where the browser is in charge of managing the CRLs. I object to it for two reasons:
the amount of data: if you use one browser and you are the only user on your ISP link, it may be sustainable (IN THE WORST CASE SCANARIO, in 2022 it was 8 GB plus updates for LE alone), but how much data are you downloading if you are a company with hundreds of browsers? Is it sustainable at all on mobile phones?
certificates are used by many other services, including e-mail, so the idea that each client must manage the CRLs is sheer madness.
I am asking LE to postpone OCSP deprecation and engage in open discussion with the community, instead of enforcing a one-sided decision.
Mozilla, for example, is using CRLite. This uses a bloom filter for extreme compression. In the blog post as of 2020, 152 million certificates can be compressed to 1.3mb
Unfortunately, very few people were able to implement OCSP correctly, it causes excessive load to Let's Encrypt, and can result in outages which affect more than just site operators. I doubt Let's Encrypt will be altering their stance
Not to mention, short lived certificates further erode OCSPs usability.
I certainly understand your frustration, that other systems not using OCSP stapling correctly has been enough to convince Let's Encrypt to stop supporting it, even though you might be using it in a helpful and privacy-preserving manner.
But Let's Encrypt isn't the only CA, nor even the only free CA. I don't know if removal of OCSP is going to be an industry trend, but I haven't heard of other CAs getting rid of it yet.
I suspect other CAs are watching to see how the OCSP sunset goes. Chrome and Edge for example don't even properly check OCSP. That makes up somewhere around 70% of all browser users.
And Safari on iPad doesn't care if a Must-Staple cert has no staple.
@patch-work Your same comments have been discussed at some length when the OCSP announcement was first made. The plain fact is that OCSP has been broken for a long time throughout the ecosystem. It has had many years to become useful but it just didn't happen. Swimming against that tide is hopeless.
The long-term way forward is very short-lived certs. LE resources freed from OCSP are better spent on that effort (which is currently in test to rollout generally later this year).
Please see the below threads. These are not the only discussions of OCSP just a couple I bookmarked. Search this forum for others.
This is a thorough look at the state and history of OCSP written Jan 2025
The long-term way forward is very short-lived certs.
When something brakes, one needs time to fix it.
In this case, nothing broke on my side of the wire. My fault was to implement a best practice in the RFC standards track, and now I must find the time to undo the well-oiled machinery because ... a browser I do not use decided in 2012 that safety was slowing them down, and my CA agrees. So, now I must find the time to ... undo it, against my will, and I have time until the 26th.
In the case of 3-months certificates, I already had problems adopting them through DNSSEC, because LE insists in reading the slaves instead of the master. When certificates update, the process takes 2 weeks to complete, because of DNS propagation issues on the Registrar's side, because of LE's own downtime, and the local weekly cronjob.
When LE's certificates will have a lifespan of 5 days, it will be simply unsustainable to use them. Assuming the problem with the renewal of certificates will be solved on LE's side, also assuming LE will have absolutely no downtime, which is a lot of assumptions, you still cannot assume there will not be delays with the DNS slaves, and no local problems to fix on the spot, and none of us is willing to be on a dog leash anyway to check whether it broke down, every God given week.
Your renewal strategy is deeply flawed. I can see how shorter lived certs will be difficult for you until you resolve that.
But, short lived certs (6day-ish) will be an option not a requirement. But, the industry max lifetime for certs generally will be 47 days by 2029. Your current mechanism won't hold up.
Sounds like you need general advice on best practices. You should start a new thread about that.
If you are unhappy with Let's Encrypt there are other Certificate Authorities that are free and support ACME. In tech things change. It's the way of life. Perhaps it is time for you to step back and review your solution.
You mean "DNS service provider"? Because I don't see how the registrar plays a role in this.
Also, DNSSEC shouldn't be an issue. If it is, your DNS is probably broken and you should somehow fix it. Maybe change DNS service provider. And that's not just related to LE, chances are if LE fails somehow, other clients on the internet do too.
I am using LE's recommended mechanism to update certificates through DNS.
The problem is LE not reading from the master DNSSEC. This causes LE to read the DNS slaves. When the slaves are slow, the update mechanism fails. Despite other frantic improvements at LE, no progress was made to fix this old problem.
LE doesn't really care about how the DNS zone is set up, it just follows the DNS tree from the root down to the authorative nameserver. (Although it does care if it's broken of course..) It doesn't care if it's the primary or secondary.. Or if updates between those two are slow. It's up to the DNS service provider/user to make sure all the authorative nameservers are up to date.
It doesn't make much sense that the secondary nameservers take WEEKS to update.. That's just, well, ridiculous.. Not something you can blame LE for.
It might be that your specific DNS situation simply isn't compatible with short-lived certificates.
Then your registrar also acts as a DNS service provider. That's not always the case though, that's why I'd prefer using the 'correct' (IMO) terminology "DNS service provider".
No Osiris, I am the DNS provider. I use the Registrar as DNS slave. When the certificates update, I change the master DNS on my servers. The Registrar reads them and propagates them. LE ought to improve the mechanism to read from the master DNS.
You are the DNS service provider? Oh.. And you're not able to push updates from your primary nameservers to the secondary nameservers of the registrar? Hmkay..
Time to change registrar perhaps? Or ditch those secondary nameservers entirely?
That said, I don't think LE is removing support for current 90 days certificates any time soon (not planned), so there's that..
You are the DNS service provider? Oh.. And you're not able to push updates from your primary nameservers to the secondary nameservers of the registrar? Hmkay..
The Registrar does not allow for "push updates". They use a different, timed mechanism.
LE downtime is rare and even when occurs is short.
If that weekly cronjob is doing the renewal that isn't best practice. Checking and trying renewal twice / day is default for Certbot, for example. No one would have advised to only do that once / week.
Yeah, but even then, if your DNS 'partner' only updates their secondary nameservers once a week, you're in trouble with 7 days validity certificates anyway..
But those certs aren't mandatory or anything, so shouldn't really be a problem to begin with. (For now. Until the CA/B Forum decides all certificates should be short-lived some day in the future..)
But that's all rather offtopic w/r to OCSP Which isn't all that exciting either though
You can use CNAME to delegate the _acme-challenge record from your primary DNS system to a secondary provider. You would only need to set the delegating record a single time.
I don't mean to be rude by saying this, but the bulk of your complaints are due to misinterpretations and misunderstandings.
Which isn't all that exciting either though 