Decreasing Certificate Lifetimes to 45 Days

Submitted ⁨⁨7⁩ ⁨hours⁩ ago⁩ by ⁨artiman@piefed.social⁩ to ⁨selfhosted@lemmy.world⁩

https://letsencrypt.org/2025/12/02/from-90-to-45.html

Let’s Encrypt will be reducing the validity period of the certificates we issue. We currently issue certificates valid for 90 days, which will be cut in half to 45 days by 2028.
This change is being made along with the rest of the industry, as required by the CA/Browser Forum Baseline Requirements, which set the technical requirements that we must follow. All publicly-trusted Certificate Authorities like Let’s Encrypt will be making similar changes. Reducing how long certificates are valid for helps improve the security of the internet, by limiting the scope of compromise, and making certificate revocation technologies more efficient.

source

Comments

Sort:hotnew top

Passerby6497@lemmy.world ⁨2⁩ ⁨hours⁩ ago
I’ve been dreading this switch for months (I still am, but I have been, too!) considering this year and next year will each double the amount of cert work my team has to do. But, I’m hopeful that the automation work I’m doing will pay off in the long run.

source
- non_burglar@lemmy.world ⁨2⁩ ⁨hours⁩ ago
  Are you not using LE certbot to handle renewals? I can’t even imagine doing this manually.
  
  source
  - Passerby6497@lemmy.world ⁨2⁩ ⁨hours⁩ ago
    Personally, yes. Everything is behind NPM and SSL cert management is handled by certbot.
    
    Professionally? LOL NO. Shit is manual and usually regulated to overnight staff. Been working on getting to the point it is automated though, but too many bespoke apps for anyone to have cared enough to automate the process before me.
    
    source
Jozav@lemmy.world [bot] ⁨2⁩ ⁨hours⁩ ago
Reducing the validity timespan will not solve the problem, it only reduces the risk. And how big is that risk really? I’m an amateur and would love to see some real malicious case descriptions that would have been avoided had the certificate been revoked earlier…

Anybody have some pointers?

source
Arghblarg@lemmy.ca ⁨7⁩ ⁨hours⁩ ago
So what’s the floor here realistically, are they going to lower it to 30 days, then 14, then 2, then 1? Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?

It is ignoring the elephant in the room – the central root CA system. What if that is ever compromised?

Certificate pinning was a good idea IMO, giving end-users control over trust without these top-down mandated cert update schedules. Don’t get me wrong, LetsEncrypt has done and is doing a great service within the current infrastructure we have, but …

I kind of wish we could just partition the entire internet into the current “commercial public internet” and a new (old, redux) “hobbyist private internet” where we didn’t have to assume every single god-damned connection was a hostile entity. I miss the comraderie, the shared vibe, the trust. Yeah I’m old.

source
- atzanteol@sh.itjust.works ⁨7⁩ ⁨hours⁩ ago
  
  Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?
  
  Automate your certificate renewals. You should be automating updates for security anyway.
  
  source
  - billwashere@lemmy.world ⁨1⁩ ⁨hour⁩ ago
    But can you imagine the load on their servers should it come to this? And god forbid it goes down for a few hours and every person in the world is facing SSL errors because Let’s Encrypt can’t create new ones.
    
    This continued shortening of lifespans on these certs is untenable at best. Personally I have never run into a situation where a cert was stolen or compromised but obviously that doesn’t mean it doesn’t happen. I also feel like this is meant to automate all cert production which is nice if you can. Right now, at my job, all cert creation requires manually generating a CSR, submit it to a website, wait for manager approval, and then wait for creation. Then go download the cert and install it manually.
    
    If I have to do this everyday for all my certs I’m not going to be happy. Yes this should be automated and central IT is supposed to be working on it but I’m not holding my breath.
    
    source
  - dan@upvote.au ⁨7⁩ ⁨hours⁩ ago
    This is one of the reasons they’re reducing the validity - to try and convince people to automate the renewal process. That and there’s issues with the current revocation process (for incorrectly issued certificates, or certificates where the private key was leaked or stored insecurely), and the most effective way to reduce the risk is to reduce how long any one certificate can be valid for.
    
    From digicert.com/…/tls-certificate-lifetimes-will-off…:
    
    In the ballot, Apple makes many arguments in favor of the moves, one of which is most worth calling out. They state that the CA/B Forum has been telling the world for years, by steadily shortening maximum lifetimes, that automation is essentially mandatory for effective certificate lifecycle management.
    
    The ballot argues that shorter lifetimes are necessary for many reasons, the most prominent being this: The information in certificates is becoming steadily less trustworthy over time, a problem that can only be mitigated by frequently revalidating the information.
    
    The ballot also argues that the revocation system using CRLs and OCSP is unreliable. Indeed, browsers often ignore these features. The ballot has a long section on the failings of the certificate revocation system. Shorter lifetimes mitigate the effects of using potentially revoked certificates. In 2023, CA/B Forum took this philosophy to another level by approving short-lived certificates, which expire within 7 days, and which do not require CRL or OCSP support.
    
    source
    -> View More Comments
- JASN_DE@feddit.org ⁨7⁩ ⁨hours⁩ ago
  
  So what’s the floor here realistically, are they going to lower it to 30 days, then 14, then 2, then 1?
  
  LE is beta-testing a 7-day validity, IIRC.
  
  Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?
  
  No, those are expected or even required to be automated.
  
  source
  - dan@upvote.au ⁨6⁩ ⁨hours⁩ ago
    7-day validity is great because they’re exempt from OCSP and CRL. Let’s Encrypt is actually trying 6-day validity, not 7: letsencrypt.org/2025/01/16/6-day-and-ip-certs
    
    Another feature Let’s Encrypt is adding along with this is IP certificates, where you can add an IP address as an alternate name for a certificate.
    
    source
    -> View More Comments
- ByteJunk@lemmy.world ⁨2⁩ ⁨hours⁩ ago
  Partition the internet… Like during the Morris worm of '88, where they had to pull off regional networks to prevent the machines from being reinfected?
  
  The good old days were, maybe, not that good. :)
  
  source
- Ooops@feddit.org ⁨1⁩ ⁨hour⁩ ago
  
  Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?
  
  Certbots by default checks twice a day if it’s old enough to be be due for a renewal… So a change from 90 to 1 day will in practice make no difference already…
  
  source
- dan@upvote.au ⁨7⁩ ⁨hours⁩ ago
  The current plan is for the floor to be 47 days. digicert.com/…/tls-certificate-lifetimes-will-off…
  
  source
- cron@feddit.org ⁨7⁩ ⁨hours⁩ ago
  The best approach for securing our CA system is the “certificate transparency log”. All issued certificates must be stored in separate, public location. Browsers do not accept certificates that are not there.
  
  This makes it impossible for malicious actors to silently create certificates. They would leave traces.
  
  source
  - False@lemmy.world ⁨4⁩ ⁨hours⁩ ago
    Isn’t this just CRL in reverse? Part of the point of cryptographically signing a cert is so you don’t have to do this if you trust the issuer.
    
    source
    -> View More Comments
  - Arghblarg@lemmy.ca ⁨7⁩ ⁨hours⁩ ago
    This seems like a good idea.
    
    source
    -> View More Comments
- AlmightyDoorman@kbin.earth ⁨7⁩ ⁨hours⁩ ago
  Not exactly what you mean because there are also bad actors but take a look at i2p, in some ways it feels like an retro internet.
  
  source
- slazer2au@lemmy.world ⁨7⁩ ⁨hours⁩ ago
  Seeing as most root CA are stored offline compromising a server turned off is not really possible.
  
  source
  - AA5B@lemmy.world ⁨2⁩ ⁨hours⁩ ago
    Signing (intermediate) certs have been compromised before. That means a bad actor can issue fake certs that are validated up to your root ca certs
    
    While you can invalidate that signing cert, without useful and ubiquitous revocation lists, there’s nothing you can do to propagate that.
    
    A compromised signing certs, effectively means invalidating the ca cert, to limit the damage
    
    source
  - Arghblarg@lemmy.ca ⁨7⁩ ⁨hours⁩ ago
    Oh, I’m really just pining for the days before the ‘Eternal September’, I suppose. We can’t go back, I know. :/
    
    source
probable_possum@leminal.space ⁨5⁩ ⁨hours⁩ ago
It’s the “change your password often odyssey” 2.0. If it is safe, it is safe, it doesn’t become unsafe after an arbitrary period of time (if the admin takes care and revokes compromised certs). Or am I missing the point?

source
- cron@feddit.org ⁨3⁩ ⁨hours⁩ ago
  Short lifespans are also great when domains change their owner. With a 3 year lifespan, the old owner could possibly still read traffic for a few more years.
  
  When the lifespan ist just 30-90 days, that risk is significatly reduced.
  
  source
- LastYearsIrritant@sopuli.xyz ⁨4⁩ ⁨hours⁩ ago
  The point is, if the certificate gets stolen, there’s no GOOD mechanism for marking it bad.
  
  If your password gets stolen, only two entities need to be told it’s invalid. You and the website the password is for.
  
  If an SSL certificate is stolen, everyone who would potentially use the website need to know, and they need to know before they try to contact the website. SSL certificate revocation is a very difficult communication problem, and it’s mostly ignored by browsers because of the major performance issues it brings having to double check SSL certs with a third party.
  
  source
  - mbirth@lemmy.ml ⁨3⁩ ⁨hours⁩ ago
    
    The point is, if the certificate gets stolen, there’s no GOOD mechanism for marking it bad.
    
    That’s what OCSP is for. Only Google isn’t playing along as per that wiki entry.
    
    source
  - wildbus8979@sh.itjust.works ⁨2⁩ ⁨hours⁩ ago
    That’s what Carla are for.
    
    source
  - Lyra_Lycan@lemmy.blahaj.zone ⁨4⁩ ⁨hours⁩ ago
    But browsers have a marker for dangerous sites - surely Cloudflare, Amazon or Google should have a report system and deliver warnings at the base
    
    source
    -> View More Comments
myfunnyaccountname@lemmy.zip ⁨2⁩ ⁨hours⁩ ago
Coming soon. Daily certs. Just $19.99 a month.

source
imetators@lemmy.dbzer0.com ⁨4⁩ ⁨hours⁩ ago
As some selfhosting novice who uses NPM with auto renewal - I feel that I shouln’t be ocncerned.

source
- mjr@infosec.pub ⁨1⁩ ⁨hour⁩ ago
  Check your autorenewal failure alerts go somewhere you’ll react to.
  
  source
corsicanguppy@lemmy.ca ⁨1⁩ ⁨hour⁩ ago
The five-assed monkey of cert lifetimes.

As useless measures go this will certainly be one; especially while CRLs are a thing.

source
Valmond@lemmy.world ⁨6⁩ ⁨hours⁩ ago
And you still can’t self certify.

It’s cute the big players are so concerned with my little security of my little home server.

Or is there a bigger plan behind all this? Like pay more often, lock in to government controlled certs (already done I guess because they control DNS and you must have a “real” website name to get a free cert)?

I feel it’s 50% security 50% bullshit.

source
- farcaller@fstab.sh ⁨6⁩ ⁨hours⁩ ago
  You can absolutely run your own CA and even get your friends to trust it.
  
  source
  - CosmicTurtle0@lemmy.dbzer0.com ⁨3⁩ ⁨hours⁩ ago
    Yes you can but the practicality of doing so is very limiting. Hell I ran my own CA for my own internal use and even I found it annoying.
    
    The entire CA ecosystem is terrible and only exists to ensure connections are encrypted at this point. There’s no validation or any sort of authority to say one site is better than another.
    
    source
  - fxdave@lemmy.ml ⁨6⁩ ⁨hours⁩ ago
    not all phones support manually adding certs
    
    source
    -> View More Comments
  - Valmond@lemmy.world ⁨6⁩ ⁨hours⁩ ago
    But you have to manually accept this dangerous cert in the browser right?
    
    Very interesting actually, do you have any experience about it or other pointers? I might just set one up myself for my tenfingers sharing protocol…
    
    source
    -> View More Comments
- stratself@lemdro.id ⁨5⁩ ⁨hours⁩ ago
  Technically something like DANE can allow you to present DNSSEC-backed self-signed certs and even allow multi-domain matching that removes the need for SNI and Encrypted Client Hello… but until the browsers say it is supported, it’s not
  
  source
- Passerby6497@lemmy.world ⁨2⁩ ⁨hours⁩ ago
  
  And you still ~~can’t~~ can self certify.
  
  Skill issue, you’ve always been able to self certify. You just have to know where to drop the self signed cert or the parent/root cert you use to sign stuff.
  
  If you’re running windows, it’s trivial to make a self signed cert trusted.
  
  source
Prove_your_argument@piefed.social ⁨7⁩ ⁨hours⁩ ago
Reducing the valid time will not solve the underlying problems they are trying to fix.

We’re just gonna see more and more mass outages over time especially if this reduces to an uncomfortably short duration. Imagine what might happen if a mass crowdflare/microsoft/amazon/google outage that goes on perhaps a week or two? what if the CAs we use go down longer than the expiration period?

Sure, the current goal is to move everybody over to ACME but now that’s yet another piece of software that has to be monitored, may have flaws or exploits, may not always run as expected… and has dozens of variations with dependencies and libraries that will have various levels of security of their own and potentially more vulnerabilities.

I don’t have the solution, I just don’t see this as fixing anything. What’s the replacement?

source
- fistac0rpse@fedia.io ⁨6⁩ ⁨hours⁩ ago
  clearly the most secure option is to have certificates that are only valid for 30 seconds at a time
  
  source
  - fxdave@lemmy.ml ⁨6⁩ ⁨hours⁩ ago
    Let’s be extra safe. New cert per every request
    
    source
cupcakezealot@piefed.blahaj.zone ⁨7⁩ ⁨hours⁩ ago
assuming “rest of the industry” in this context refers to ssl seller lobby.

source
- dan@upvote.au ⁨7⁩ ⁨hours⁩ ago
  Yes, this requirement comes from the CA/Browser Forum, which is a group consisting of all the major certificate authorities (like DigiCert, Comodo/Sectigo, Let’s Encrypt, GlobalSign, etc) plus all the major browser vendors (Mozilla, Google, and Apple). Changes go through a voting process.
  
  source
  - fluckx@lemmy.world ⁨5⁩ ⁨hours⁩ ago
    Don’t worry they’ll reduce the cost of certificates proportionally to the longevity of the certificate.
    
    Right? Anybody?
    
    << Cricket noises >>
    
    source
    -> View More Comments
- atzanteol@sh.itjust.works ⁨7⁩ ⁨hours⁩ ago
  It’s being deiven by the browsers. Shorter certs mean less time for a compromised certificate to be causing trouble.
  
  cabforum.org/working-groups/…/requirements/
  
  source
  - helix@feddit.org ⁨6⁩ ⁨hours⁩ ago
    most trouble is probably caused in the first few days. Doesn’t matter if it’s 45 or 90 days, it would have to be a few hours to be meaningfully short. Given that automating things like this is annoying sometimes, you’ll be sure people will max out the 45 days…
    
    I’m pretty sure it’s the SSL seller lobby just wanting more money, tbh. Selling snake oil security.
    
    source
    -> View More Comments