Top
Best
New

Posted by schmuckonwheels 22 hours ago

Upcoming Changes to Let's Encrypt Certificates(community.letsencrypt.org)
295 points | 252 commentspage 2
rswail 11 hours ago|
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?

londons_explore 19 hours ago||
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 16 hours ago||
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 17 hours ago||
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 15 hours ago||
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.

azov 18 hours ago||
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.

jmb99 17 hours ago|
> What we ended up with is every site needs a constant blessing from some semi-centralized authority to remain accessible.

Do you have any examples of sites that have been blocked by the free ACME providers?

azov 14 hours ago||
If you mean that sites with expired certificates may technically be accessible if one jumps through enough hoops and ignores scary warnings - yes, of course you’re right.

Maybe this will just teach everyone to click through SSL warnings the same way they click through GDPR popups - for better or worse.

simonsarris 20 hours ago||
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 20 hours ago||
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 19 hours ago||
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 20 hours ago||
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 18 hours ago||
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.

notherhack 20 hours ago||
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 19 hours ago||
> 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 19 hours ago||
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 19 hours ago||
How much does that end up costing? I'm interested to know for my own personal domain.
jacquesm 19 hours ago||
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.
PunchyHamster 18 hours ago||
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
wrs 21 hours ago||
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 11 hours ago|
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.

maltris 15 hours ago|
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?
More comments...