Top
Best
New

Posted by schmuckonwheels 12/15/2025

Upcoming Changes to Let's Encrypt Certificates(community.letsencrypt.org)
321 points | 322 commentspage 2
londons_explore 12/15/2025|
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.

jmb99 12/16/2025||
I just checked, and one of my web servers has an uptime of 845 days, last login May 2 of last year. Based on the shell history I don’t believe I’ve touched the letsencrypt config on it since I set it up in 2020 ish.
gonzo41 12/16/2025||
I agree, however the simplest place for a static bit of the web seems to be an s3 bucket with cloudfront or something similar.
londons_explore 12/16/2025||
Please accept the new T&C's within 90 days or your account will be terminated...

2 factor Auth now compulsory.

Please validate your identity with our third party identity provider so we can confirm you are not on the sanctions list. If you do not, your account will be blocked.

Etc etc. Every third party service requires at least a little work and brainspace.

gruez 12/15/2025||
>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?

infogulch 12/15/2025|
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)
notherhack 12/15/2025||
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.

zaik 12/15/2025||
> which means you're at their mercy

Let's Encrypt could easily refuse to issue a certificate for a certain domain, even if you don't have a registered account. I don't see much difference.

cheeze 12/15/2025||
AWS Certificate Manager manages this all for you via DNS validation.

Granted, you're locked into their ecosystem, can't export PK, etc. so it's FAR from a perfect solution here but I've actually been pretty impressed with the product from a "I need to run my personal website and don't want to have to care about certificates" perspective. Granted, you're paying for the cert, just not directly.

I agree with your statement completely though.

eterm 12/15/2025||
How much does that end up costing? I'm interested to know for my own personal domain.
wrs 12/15/2025||
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.

phasmantistes 12/16/2025|
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.

jacquesm 12/15/2025||
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.
simonsarris 12/15/2025||
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.
notherhack 12/15/2025||
That was a smart move but those days are over. Your existing 15 year certs will continue to be accepted until they expire but then you'll have to get a new cert and be in the same 45-day-churn boat the rest of us are.
NoahZuniga 12/15/2025||
The cloudflare 15 year cert is one they issue privately and that they only use to authenticate your origin. Cloudflare manages the certificates for connections coming from the web.
SchemaLoad 12/15/2025||
I wouldn't be surprised if eventually clients just start rejecting certificates that are too long. Imagine if someone bought a domain, but a previous owner is holding a certificate for it that lasts 15 years.

At least under the new scheme if you let the domain sit for 45 days you'll know only you hold valid certificates for it.

toddgardner 12/15/2025||
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.

ChrisArchitect 12/15/2025||
Related:

Decreasing Certificate Lifetimes to 45 Days

https://news.ycombinator.com/item?id=46117126

PunchyHamster 12/15/2025||
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
rswail 12/16/2025|
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?

cpach 12/17/2025|
So, you will need a CA that are trusted by all parties involved, and one that is not tied to the Web PKI ecosystem.

One option is to build your own PKI with it’s own root certificate, and then tell all involved parties to import that into their root cert stores.

That’s a lot of work though. If you want to, I think you can buy “private-PKI-as-a-service” from companies like Digicert and Sectigo. And probably from AWS/Google/Azure too.

I don’t know the specifics of your environment but it might also be possible to do encryption and signature verification above the transport layer. I.e. sign (and possibly encrypt) the payload itself. Then you might not need mTLS for the connection itself.

rswail 12/17/2025||
Yeah, we've gone down the private CA PKI route, trouble is that you need to start managing your roots and your CA/RA properly, it needs to be auditable etc etc.

Cost of a Private CA on AWS is $400/month for a CA that issues certs more than 7 days in duration. That's for one signing CA. If you want PKI with a root, intermediates, and leaves, then the root has to issue intermediates every 7 days as well, or you have your root signing the leaves.

On top of that is the infrastructure of the RA, because if you want to automatically issue certs (eg to devices in the field), you need to implement ACME, but you can't necessarily use DNS methods for verification.

So you have to roll your own, from a Secure Element that contains a base key that gets diversified by the device's own ID, so it can sign a CSR or an internal DNS server that adds an TXT record for the dns-01 challenge.

Then you need the human processes of building the RA, authorizations, ceremonies, etc etc.

Or you cut corners.

More comments...