- The certificate lifetime decrease, to 45 days, was discussed in: 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.
- 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.
- 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.
- 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").
Edit: TIL about https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
by noirscape
5 subcomments
- 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.
by notepad0x90
2 subcomments
- 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.
- 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.
- Don't miss DNS-PERSIST-01 challenge introduction, a related change: https://letsencrypt.org/2025/12/02/from-90-to-45#making-auto...
It's not final yet, but interesting development.
by londons_explore
2 subcomments
- I miss the days when I could set up some random Apache server and leave it running with zero attention for a decade or two.
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.
- 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.
- 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.
- >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?
by notherhack
2 subcomments
- 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.
There really is no alternative to LE.
- 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.
- 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.
by toddgardner
0 subcomment
- For all the folks worried about how hard automation is going to be, this is what my team and I have been working on for the past year:
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.
by simonsarris
2 subcomments
- 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.
- If I want a client certificate, it sounds like that won't be available any longer from LetsEncrypt
> These new intermediates do not contain the “TLS Client Authentication” Extended Key Usage due to an upcoming root program requirement. We have previously announced our plans to end TLS Client Authentication starting in February 2026, which will coincide with the switch to the Generation Y hierarchy.
So we use this to authenticate based on our fixed-IP/PTR/DNS to connect server to server to a 3rd party.
If we don't have the Client Authentication bit set, then the cert will be invalid for outgoing connections.
What do we use instead?
by PunchyHamster
0 subcomment
- 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
- Wondering: Is there a good tool for centralized ACME cert management when one runs a large infrastructure, highly available, multi location where it makes little sense to run the ACME client directly on each instance or location?
- When are we going to get certificates signed by multiple vendors?
- 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 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?
by PunchyHamster
0 subcomment
- 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"
- Did I understand that correctly that I will be able to get a certificate for an IP?
by ChrisArchitect
0 subcomment
- Related:
Decreasing Certificate Lifetimes to 45 Days
https://news.ycombinator.com/item?id=46117126
by kmeisthax
2 subcomments
- 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.
- [flagged]
Hacker News