this post was submitted on 15 Apr 2025
97 points (99.0% liked)

Sysadmin

8607 readers
162 users here now

A community dedicated to the profession of IT Systems Administration

No generic Lemmy issue posts please! Posts about Lemmy belong in one of these communities:
[email protected]
[email protected]
[email protected]
[email protected]

founded 2 years ago
MODERATORS
 

From today until March 15, 2026, the maximum lifetime for a TLS certificate is 398 days.

As of March 15, 2026, the maximum lifetime for a TLS certificate will be 200 days.

As of March 15, 2027, the maximum lifetime for a TLS certificate will be 100 days.

As of March 15, 2029, the maximum lifetime for a TLS certificate will be 47 days.

What's everyone's opinion on this? I think from a security standpoint their reasoning is valid and in many cases it's very easy to automate the renewal with ACME or something else. But there's likely gonna be legacy stuff still around in 2029 that won't be easy to automate.

all 21 comments
sorted by: hot top controversial new old
[–] enumerator4829 48 points 18 hours ago (2 children)

This will be so much fun for people with legacy systems

[–] [email protected] 23 points 18 hours ago* (last edited 18 hours ago) (2 children)

Self signed certs about to get even more popular.

[–] [email protected] 4 points 11 hours ago (1 children)

Self signed certs still have to abide. It’s the browser that checks it not the issuer. Now granted in most cases you already get a non trusted warning that most sysadmins skip…

[–] [email protected] 1 points 1 hour ago

The cert is what tells the browser how long it lasts, so I'm not sure how the browser can stop you from using a 10 year self signed cert or one from your own CA

[–] enumerator4829 10 points 17 hours ago

Tony Stark was able to build his CA in a cave! With a bunch of dice!

[–] [email protected] 9 points 16 hours ago

This way it will gradually ramp up the pain tho. If they went straight to 47 days, basically the entire internet would be gone for a few days.

[–] [email protected] 28 points 17 hours ago* (last edited 15 hours ago) (3 children)

Are compromised private keys that much of a problem in the real world to merit such a pain in the ass, heavy handed "solution"? On paper, sure, it makes sense. In practice, you're forcing people to complicate the process by introducing, until now, unnecessary automation and introducing the possibility of brand new points of vulnerability.

I say this as someone who does maintain legacy systems (i.e. systems), so take it with a very angry, frazzled grain of salt. But I've done this for ~~years~~ decades and many, many systems and to my knowledge, I've never had a compromised private key.

This just seems like people who constantly lose their house keys mandating that everyone else change their locks as often as they do.

[–] [email protected] 6 points 17 hours ago

One issue is that browsers and other clients have a difficult time handling certificate revocation. Let's Encrypt is stopping support for OCSP, and that had a lot of privacy implications where a CA could tell who is going to what site, based on the requests to check certificate revocation. Let's Encrypt is moving to CRLs, but the size of the CRL is very large the more certificates you have. For Let's Encrypt with only a 90 day validity period, their CRL is smaller than a CA which has certificates as much as 398 days old.

The size of the CRL is something not only CAs have to manage, on the client side, you may have to check a 10MB file to see if the certificate for the site you're connecting to is still trusted by the CA. With many CAs, these CRLs will take up a lot of space on disk, and need to be updated often. Mozilla published a system called CRLite which uses Cascading Bloom Filters to keep track of revoked certificates in the browser, which will save a lot of space. Having a constrained set of revoked certificates is useful to ensure the bloomfilter won't be too large for the browser to store and manage.

[–] [email protected] 5 points 17 hours ago

It’s not a problem… until it is.

And it has been before.

And probably will be again.

[–] [email protected] 2 points 17 hours ago

I like that metaphor, I'm gonna save it. And agreed, there's going to be issues with legacy systems.

Luckily, at my current job, all of our outside-facing legacy services already go through an SSL terminating reverse proxy. And we then use self-signed certs with much longer validity for internal traffic where needed.

[–] [email protected] 2 points 12 hours ago

Doesn't really affet me much, as my LE cronjob will update the cert either way. Doesn't really matter if it's 90 days or 47 (what a weird number of days)

[–] [email protected] 6 points 18 hours ago

My little corner of the business has started migrating our certs to let's encrypt.

Hope it catches on else where

[–] [email protected] 5 points 18 hours ago (1 children)

I can’t wait for the day when we have to refresh them hourly.

[–] [email protected] 6 points 12 hours ago

ephemeral single use certs when?

[–] [email protected] 3 points 17 hours ago* (last edited 17 hours ago) (1 children)

If I understand this correctly, it only affects certificates issued by public CAs (certificates for public websites, for example). So for certs issued by a company CA (e.g. for internal infrastructure), it should not apply. Can anyone confirm?

[–] [email protected] 5 points 15 hours ago

True. Technically the bounds for the validity period are from Jan 1, 1950 to Dec 31, 9999.

Source

[–] [email protected] 2 points 17 hours ago (1 children)

Digicert is such a shitty CA.

[–] [email protected] 2 points 16 hours ago (1 children)

Oh, I agree. This change will affect all CAs however. And their post seemed to contain the most amount of information.

[–] [email protected] 1 points 16 hours ago

I just had to get it out of my system.

[–] [email protected] 2 points 18 hours ago

I like it. This action is inevitable in my opinion, and there will always be legacy systems regardless of the timeline, better start sooner than later.