These short certificate lifetimes make Let's Encrypt a central point of failure for much of the Internet. That's a concern. Failure may be technical or political, too.
I am at the point of looking forward to it. The CA/B is so unhinged and so unaccountable and the appetite to fix it is so small, a broad scale collapse of the Internet caused by the CA/B's incompetence is looking like the only way to finally end their regime.
Can you explain how shorter certificate lifetimes make LE more of a single point of failure? I can squint and see an argument for CA diversity; I struggle to see how reducing certificate lifetimes increases CA centralization.
I'm seeing this hot take a lot but it doesn't make sense. Are people worried than LE is going to have a 45 day outage or something? ACME is an open standard with other implementations so I'm having trouble seeing the political central point of failure too.
It's okay for something to be a good thing and to celebrate it. We don't have to frown about everything.
IMO this is a policy change that can Break the Internet, as many archived/legacy sites on old-school certificates may not be able to afford the upfront tech or ongoing labor to transition from annual to effectively-monthly renewals, and will simply be shut down.
And, per other comments, this will make LE the only viable option to modernize, and thus much more of a central point of failure than before.
But Let's Encrypt is not responsible for this move, and did not vote on the ballot.
It will make ACME the only viable option. I believe there is a second free ACME CA and other CAs will likely adopt ACME if they want to stay relevant.
Ideally, this will take less ongoing labor than annual manual rotations, and I'd argue sites that can't handle this would have been likely to break at the next annual rotation anyways.
If they have certificates managed by hosters, the hosters will deal with it. If they don't, then someone was already paying for the renewal and handling the replacement on the server side, making it much more likely that it will be fixed.
> Next year, you’ll be able to opt-in to 45 day certificates for early adopters and testing via the tlsserver profile. In 2027, we’ll lower the default certificate lifetime to 64 days, and then to 45 in 2028.
The good news is that the CAs signed their own death warrant with this change. If switching to ACME is more or less mandatory, what purpose do paid certificates serve? Your options are to use LE, switch to non-CA-issued encryption, or drop encryption entirely.
Certificate rotation/renewal has been the biggest headache of my IT career. It’s always after the fact. It’s always a pain point. It’s always an argument with accounting over costs. It sucks. I’m glad ACME exists but man this whole thing is a cluster fuck.
Whole IT teams are just going to wash their hands of this and punt to a provider or their cloud IaaS.
> IMO this is a policy change that can Break the Internet
Unfortunately, the people making these decisions simply do not care how they impact actual real world users. It happens over and over that browser makers dictate something that makes sense in a nice, pure theoretical context, but sucks ass for everyone stuck in the real world with all its complexities and shortcomings.
I have been saying it since the beginning that we are centralizing all the power of the internet to one organization and that this a bad thing, yet I get downvoted every time. One organization is going to have a say on whether or not you can have a website on the internet, how is this objectively a good thing?
Nginx and Apache are free and both can be trivially automated with ACME bot. Both can be used to set up a reverse proxy in front of legacy sites or applications.
This is not centralizing everything to Let's Encrypt. it's forcing everyone to use ACME, and many CAs support ACME (and those that don't probably will soon due to this change).
It's more complicated than that. Apple (along with Google and Mozilla) basically held the CA's hostage. They started unilaterally reducing lifetimes. It was happening whether the CAB approved it or not.
The vote was more about whether the CAB would continue to be relevant. "Accept the reality, or browsers aren't even going to show up anymore".
>IMO this is a policy change that can Break the Internet, as many archived/legacy sites on old-school certificates may not be able to afford the upfront tech or ongoing labor to transition from annual to effectively-monthly renewals, and will simply be shut down.
This is just fear-mongering, legacy sites still need to update their tech and going fully automatic for cert renewals leads to less maintenance burden then renewing them manually.
>If you’re requesting certificates from our tlsserver or shortlived profiles, you’ll begin to see certificates which come from the Generation Y hierarchy this week. This switch will also mark the opt-in general availability of short-lived certificates from Let’s Encrypt, including support for IP Addresses on certificates.
Does that mean IP certificates will be generally available some time this week?
Now all servers can participate in Encrypted Client Hello for enhanced user privacy: if clients open TLS connections with ECH where the server IP is used in the ClientHelloOuter and the target SNI domain is in the encrypted ClientHelloInner, then eavesdroppers won't be able to read which domain the user is connecting to.
This vision still needs a several more developments to land before it actually results in an increment in user privacy, but they are possible:
1. User agents can somehow know they can connect to a host with IP SNI and ECH (a DNS record?)
2. User agents are modified to actually do this
3. User agents use encrypted DNS to look up the domain
4. Server does not combine its IP cert with it's other domain certs (SAN)
Insane that they're dropping client certificates for authentication. Reading the linked post, it's because Google wants them to be separate PKIs and forced the change in their root program.
They aren't used much, but they are a neat solution. Google forcing this change just means there's even more overhead when updating certs in a larger project.
Is that a temporary situation? Is it that big a deal to implement a separate set of roots for client certs? Or do you mean that the entire infrastructure is supposed to be duplicated?
I think client certificates are a good idea, although it is usually more useful to use different certificates than those for the domain names, I think. (I still think CA/Browser Forum is not very good, despite that; however, I still want to mention my point.)
The decrease in lifetimes has had a fair bit of discussion, but I haven't seen a lot of discussion about the mTLS changes. Is anyone else running into issues there? We'll be hit by it, as we use mTLS as one of several methods for our customers to authenticate the webhooks we deliver them, but haven't determined what we'll be doing yet.
The certificate offered from server to client and the certificate the server expects from the client do not need to share a CA.
This only affects you if you have a server set up to verify mTLS clients against the Let's Encrypt root certificate(s), or maybe every trusted CA on the system. You might do that if you're using the host HTTPS certificates handed out by certbot or other CAs as mTLS client certificates.
You can still generate your own mTLS key pairs and use them to authenticate over a connection whose hostname is verified with Let's Encrypt, which is what most people will be doing.
Can I ask - if you're using publicly-trusted TLS server certificates for client authentication...what are you actually authenticating?
Just that someone has a certificate that can be chained back to a trust-anchor in a common trust-store? (ie your authentication is that they have an internet connection and perhaps the ability to read).
Just curious… I’ve seen this X1/X2 convention before for CA roots. Does anyone know the origin or rationale for this?
Now we have a “Y” generation showing up, but it seems like whoever thought of “X” didn’t anticipate more than three generations, or they would have used A1/A2.
It's a good question! I know that our first root (ISRG Root X1) used that naming scheme simply because it was cross-signed by IdenTrust's root (DST Root CA X3) which used that same scheme. But where they got the scheme from, I don't know.
Using Y to denote the "next generation" of roots is a scheme I came up with in the past year while planning our YE/YR ceremony, so it's certainly not something that people were thinking about when they named the first roots.
I'm kind of had enough of unnecessary policy ratcheting, it's a problem in a every industry where a solution is not possible or practical; so the knob that can be tweaked is always turned. Same issue with corporate compliance, I'm still rotating password, with 2fa, sometimes three or four factors for an environment, and no one can really justify it, except the fear that not doing more will create liability.
Let's Encrypt, you're not even a for-profit business; there's nobody you need to shield the blow from. Just say "we're reducing certificate lifetimes to comply with CA/Browser Forum rules". You don't need to do the cowardly "replace lower with change" in the headline thing.
What is the point of shortening the life time to 45 days?
Why not 60 seconds? That's way more secure. Everything is automated after all, so why risk compromised certificate for such a long period, like 45 days?
Or how about we issue a new certificate per request? That should remove most of the risks.
I used to be knee deep in PKI stuff, now I hardly pay attention.
Two quick questions:
1 - Are there any TLS libraries that enable warnings when certs are nearing expiration?
2 - Are there any extensions in the works (or previous failed attempts) for TLS to have the client validate the next planned certificate and signal both ends when that fails?
after some failures with Let's Encrypt (almost certainly my fault wrt auto renewal) I switched to free 15 year Cloudflare certs instead and I'm very happy not worrying about it any more.
I know this is a good thing, but I've struggled a lot on systems that don't have good/reliable NTP time updates.
Also, at some point in the lifetime graph, you start getting diminishing returns. There aren't many scenarios where you get your private keys stolen, but the bad guys couldn't maintain access for more than a couple of weeks.
In my humble opinion, if this is the direction the CA/B and other self-appointed leaders want to go, it is time to rethink the way PKI works. We should maybe stop thinking of LetsEncrypt as a CA but it (and similar services) can function as more of a real-time trust facilitators? If all they're checking for is server control, then maybe a near-real-time protocol to validate that, issue a cert, and have the webserver use that immediately is ideal? Lots of things need to change for this to work of course, but it is practical.
Not so long ago, very short DNS TTL's were met with similar apprehension. Perhaps the "cert expiry" should be tied to the DNS TTL. With the server renewing much more frequently (e.g.: If the TTL is 1 hour, the server will renew every 15 minutes).
Point being, the current system of doing things might not be the best place to experiment with low expiry lifetimes, but new ways of doing things that can make this work could be engineered.
The other CAs with a free tier that I'm aware of (zerossl, ssl.com, actalis, google trust, cloudflare) require you to have an account (which means you're at their mercy), and most of them limit the number of free certs you can get to a very small number and don't offer free wildcard certs at all.
Given certificate issuance basically ended up being "do you control the DNS for this domain", I feel like all of it could've been so much simpler if it was designed like that from day one.
While I love Let's Encrypt it feels so silly to use a third party to verify I can generate a Cloudflare API key (even .well-known is effectively "can you run a webserver on said dns entry").
I am not sure how I feel about this solution. It is already painful to deal with certs on every single piece of IT equipment. Unless you create and manage your own CA and manage it, which is an extra burden, what is the point of this? This will only create more janky scripts and annoyances for very little benefit.
What's next? Enforcing email signing with SMIME or PGP?
I'm halfway tempted to go back to HTTP. You don't do breaking changes like this without giving your 'customers' a chance to stick to their ways. I have more than enough on my plate already and don't need the likes of letsencrypt to give me more work.
Not sure why they are kicking out TLS Client certs, I understand kicking them off the default profile (they REALLY had no place there, not sure why there were there in the first place), but providing no way to get one is a bit silly
The whole thing is very silly security wise anyway.
Okay, so you cert leaked. Will having it leaked for 1.5 months be substantially less dangerous than 90 days? Nope, you're fucked from the day one, it's still massively worse than "a browser asynchronously checks whether site's cert has been revoked"
You CNAME the acme challenge DNS to us, we manage all your certificates for you. We expose an API and agents to push certificates everywhere you need them, and then do real-time monitoring that the correct certificate is running on the webserver. End-to-end auditability.
We wanted TLS everywhere for privacy. What we ended up with is every site needs a constant blessing from some semi-centralized authority to remain accessible. Every site is “dead by default”.
This feels in many respects worse than what we had with plain HTTP, and we can’t even go back now.
61 comments
[ 4.7 ms ] story [ 82.9 ms ] threadThere are other CA with ACME support
Including paying CA, if you really want to pay : sectigo
It's okay for something to be a good thing and to celebrate it. We don't have to frown about everything.
Decreasing Certificate Lifetimes to 45 Days
https://news.ycombinator.com/item?id=46117126
This isn't LE's decision: a 47 day max was voted on by the CA/Browser Forum.
https://www.digicert.com/blog/tls-certificate-lifetimes-will...
https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-sch...
https://groups.google.com/a/groups.cabforum.org/g/servercert... - public votes of all members, which were unanimously Yes or Abstain.
IMO this is a policy change that can Break the Internet, as many archived/legacy sites on old-school certificates may not be able to afford the upfront tech or ongoing labor to transition from annual to effectively-monthly renewals, and will simply be shut down.
And, per other comments, this will make LE the only viable option to modernize, and thus much more of a central point of failure than before.
But Let's Encrypt is not responsible for this move, and did not vote on the ballot.
Ideally, this will take less ongoing labor than annual manual rotations, and I'd argue sites that can't handle this would have been likely to break at the next annual rotation anyways.
If they have certificates managed by hosters, the hosters will deal with it. If they don't, then someone was already paying for the renewal and handling the replacement on the server side, making it much more likely that it will be fixed.
> Next year, you’ll be able to opt-in to 45 day certificates for early adopters and testing via the tlsserver profile. In 2027, we’ll lower the default certificate lifetime to 64 days, and then to 45 in 2028.
Whole IT teams are just going to wash their hands of this and punt to a provider or their cloud IaaS.
Unfortunately, the people making these decisions simply do not care how they impact actual real world users. It happens over and over that browser makers dictate something that makes sense in a nice, pure theoretical context, but sucks ass for everyone stuck in the real world with all its complexities and shortcomings.
This is not centralizing everything to Let's Encrypt. it's forcing everyone to use ACME, and many CAs support ACME (and those that don't probably will soon due to this change).
The vote was more about whether the CAB would continue to be relevant. "Accept the reality, or browsers aren't even going to show up anymore".
I wrote a bunch about this recently: https://www.certkit.io/blog/47-day-certificate-ultimatum
"Did not vote", and "not responsible", is definitely a take...
They could call their bluff. I would. The CA/browser forum made a mistake here. And they can only get away with it if the players involved comply.
Browers have an incentive to increase the complexity, good engineers would resist that.
This is just fear-mongering, legacy sites still need to update their tech and going fully automatic for cert renewals leads to less maintenance burden then renewing them manually.
Does that mean IP certificates will be generally available some time this week?
This vision still needs a several more developments to land before it actually results in an increment in user privacy, but they are possible:
They aren't used much, but they are a neat solution. Google forcing this change just means there's even more overhead when updating certs in a larger project.
This only affects you if you have a server set up to verify mTLS clients against the Let's Encrypt root certificate(s), or maybe every trusted CA on the system. You might do that if you're using the host HTTPS certificates handed out by certbot or other CAs as mTLS client certificates.
You can still generate your own mTLS key pairs and use them to authenticate over a connection whose hostname is verified with Let's Encrypt, which is what most people will be doing.
Now we have a “Y” generation showing up, but it seems like whoever thought of “X” didn’t anticipate more than three generations, or they would have used A1/A2.
Using Y to denote the "next generation" of roots is a scheme I came up with in the past year while planning our YE/YR ceremony, so it's certainly not something that people were thinking about when they named the first roots.
Why not 60 seconds? That's way more secure. Everything is automated after all, so why risk compromised certificate for such a long period, like 45 days?
Or how about we issue a new certificate per request? That should remove most of the risks.
Two quick questions:
1 - Are there any TLS libraries that enable warnings when certs are nearing expiration?
2 - Are there any extensions in the works (or previous failed attempts) for TLS to have the client validate the next planned certificate and signal both ends when that fails?
Also, at some point in the lifetime graph, you start getting diminishing returns. There aren't many scenarios where you get your private keys stolen, but the bad guys couldn't maintain access for more than a couple of weeks.
In my humble opinion, if this is the direction the CA/B and other self-appointed leaders want to go, it is time to rethink the way PKI works. We should maybe stop thinking of LetsEncrypt as a CA but it (and similar services) can function as more of a real-time trust facilitators? If all they're checking for is server control, then maybe a near-real-time protocol to validate that, issue a cert, and have the webserver use that immediately is ideal? Lots of things need to change for this to work of course, but it is practical.
Not so long ago, very short DNS TTL's were met with similar apprehension. Perhaps the "cert expiry" should be tied to the DNS TTL. With the server renewing much more frequently (e.g.: If the TTL is 1 hour, the server will renew every 15 minutes).
Point being, the current system of doing things might not be the best place to experiment with low expiry lifetimes, but new ways of doing things that can make this work could be engineered.
strongly disagree.
Increasing complexity in a system rarely makes it more robust. It primarily makes it more expensive.
There really is no alternative to LE.
While I love Let's Encrypt it feels so silly to use a third party to verify I can generate a Cloudflare API key (even .well-known is effectively "can you run a webserver on said dns entry").
Edit: TIL about https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
What's next? Enforcing email signing with SMIME or PGP?
These days it seems like even the tiniest of projects have random sysadmin work like a compulsory change to https certs with little notice.
It's frustrating and I think has contributed to the death of the noncommercial corners of the internet.
Okay, so you cert leaked. Will having it leaked for 1.5 months be substantially less dangerous than 90 days? Nope, you're fucked from the day one, it's still massively worse than "a browser asynchronously checks whether site's cert has been revoked"
https://www.certkit.io/certificate-management
You CNAME the acme challenge DNS to us, we manage all your certificates for you. We expose an API and agents to push certificates everywhere you need them, and then do real-time monitoring that the correct certificate is running on the webserver. End-to-end auditability.
It's not final yet, but interesting development.
This feels in many respects worse than what we had with plain HTTP, and we can’t even go back now.