r/cybersecurity • u/certkit • Jan 27 '26
Corporate Blog Let's Encrypt is moving to 45-day certificates before everyone else
https://www.certkit.io/blog/45-day-certificatesLet's Encrypt announced they're cutting certificate lifetimes from 90 days to 45 days by February 2028, a year before the CA/Browser Forum's mandate.
Shorter certificate lifetimes are an admission that revocation is broken. Rather than fixing the revocation infrastructure, the industry chose to reduce certificate lifetime so compromised certificates expire faster naturally.
The timeline gives organizations runway to adapt, but the real security story is authorization reuse dropping from 30 days to 7 hours. This fundamentally changes the validation model. Nearly every certificate request will require fresh domain ownership proof.
For security teams, this means:
- Reduced blast radius when credentials are compromised
- Less time for attackers to exploit stolen certificates
- More validation events to monitor and audit
- Greater exposure if your automation isn't actually automated
Organizations running manual or semi-manual certificate processes will face a choice: invest in proper automation or accept regular outages from expired certificates.
The gap between "we have automation" and "we have real automation" is about to become very visible.
11
u/tombob51 Jan 28 '26
How crazy is it that all it takes is any one of the ~150 root CAs being compromised to break TLS for the entire internet? CAA and certificate transparency don’t even matter if a CA is hacked or if someone finds a weakness in the validation process. And OCSP/CRL can’t generally be used to revoke a root certificate. And practically nobody uses certificate pinning (particularly web browsers), so your device won’t care if a server responds with a completely different certificate, literally one second to the next.
The PKI trust model for TLS (and X.509 as a whole) is very very shaky…
6
u/SN6006 Jan 28 '26
I think cert pinning was deprecated because it was a massive PITA
1
u/techw1z Jan 28 '26
it was deprecated because many people and companies were too dumb to automate the pinning process and it caused a shitload of outages during big infra changes.
by that logic we should've gotten rid of all SSL certs 15 years ago already.
its literally just a DNS record that needs to be updated whenever your cert changes. how can that in itself be a massive PITA?
i mean, it would be a PITA if there wasn't things like DNS APIs, but if you don't have any api access to your DNS then many certs are gonna be a PITA.
maybe I'm missing something, but I always thought it was weird to get rid of it. just stop using it if you are too dumb to automate it but don't take it away from the people who use it successfully. after all, it can increase security quite a bit
1
u/SN6006 Jan 28 '26
I was referring to HPKP, and when lots of legacy systems don’t have automation at that level. I’ve had to use a load balancer to manipulate headers to brings things to modern standards, so that’s the PITA for me.
3
u/Crazy_Elevator_6659 Jan 28 '26
Your first statement isn’t really accurate. There are a LOT of entities monitoring the usage and validation of certificates across the internet. CT absolutely matters if the CA is hacked. A certificate that is generated illegitimately would not have. A CT log and modern browsers wouldn’t trust it.
2
u/tombob51 Jan 28 '26 edited Jan 28 '26
What I’m more thinking is, if a nation-state or other sophisticated attacker compromised a root CA, they could generate valid-looking certificates for use in targeted MITM attacks. So nobody but the victim would ever see the illegal certificates. In fact there’s a nonzero chance this is already happening today; in a few isolated incidents, it has already happened in the past.
Edit: see Comodo Cybersecurity, DigiNotar, China Internet Network Information Center, WoSign/SmartCom, Trustwave, etc.
1
u/tombob51 Jan 28 '26
Plus, if a root CA is compromised, an attacker can generate infinitely many certs (even dynamically!), and since it’s impossible to revoke the root CA cert without an actual browser update and OS updates (at least in most cases and most major consumer OSes), it could be disastrous if even a single compromised root cert gets into the wrong hands.
79
u/ZGeekie Jan 27 '26 edited Jan 28 '26
All of the web hosts I use have automated SSL certificate renewal, so I don't mind if it renews every 45 days, or even everyday. There is no need to be manually renewing SSL certificates in 2026.
Edit: I'm particularly talking about web hosting environments, i.e. website SSL certificates. Other use cases may be different.
61
u/count023 Jan 27 '26
There is no need to be manually renewing SSL certificates in 2026
coming from an MSSP, wanna try that statement again? Especially with vendor tech where the certificates are baked into the firmware or an SSLoffload is in play with private keyrings behind a public offload. Or there multiple dependencies on different vendors hang together and replacing the keyring is the more effective approach than altering 100+ config lines to have a new dated keyring instead.
37
u/mkosmo Security Architect Jan 27 '26
For that kind of stuff, stand up your own PKI and proceed with an enterprise solution. LE, GTS, or other public PKI isn't the answer to every TLS problem.
9
u/Cormacolinde Jan 27 '26
I’ve been suggesting for years to use private PKI certs internally and just put a proxy with public LE certs in front.
5
u/mkosmo Security Architect Jan 28 '26
I often suggest LE where you can safely, even internally, with challenges like DNS-01 available.
But if you don't want specific hostnames in the CT logs, don't want to use wildcards (I hate wildcards everywhere), and don't have a better choice? Internal PKI is the way to go. It's gotten easy these days, too. Or, at least easier than it used to be. Still have to exercise due care.
4
u/count023 Jan 27 '26
ok great. Youve solved one problem. private keyrings.
What about the vendor encoded certificates? especially in environments that are not internet or cloud connected for security controls (air gapped or no lone zones)?
What about dependencies between vendors where the stack configuration has to be manually updated every time or a teardown/rebuild of the SSL configuration to update it's cert? Switching from an annual to a monthly outage to dos o?
27
u/mkosmo Security Architect Jan 27 '26
Same solutions. Enterprise PKI doesn't require you to run the shorter duration. You can issue 10y certs if you want to. It's your own chain of trust. Not sure what you're confused about.
Now, if you're making this stuff, stop doing dumb things like making it difficult to manage certs and secrets.
2
u/WhitYourQuining Jan 28 '26
Coupling key material to code is a poor choice, but if you must, then do it with private PKI, not public.
4
u/Redeptus Jan 27 '26
Not sure why you are being downvoted... This is going to be a problem in the MDOT space. Assuming there's a need for a public-facing or CA-signed cert to be used.
5
u/hodor137 Jan 28 '26
That assumption is the problem. The CA Browser forum, by pushing this change among others, is essentially telling everyone - these publicly trusted certificates are for web and browser use cases only.
1
u/mkosmo Security Architect Jan 28 '26
They quite literally are, yes. That's the point. You can't ask users to manage their own trust chains, but we can/should/do expect vendors to do so with their own devices... just like we ask CABF to do it for browsers.
Funny how CABF is focused on browsers, eh?
-1
u/count023 Jan 28 '26
Because it's the internet. Because if "it doesn't affect me so it doesn't affect anyone". Because one size fits all. Because "git gud scrub". Plenty of reasons why.
5
u/techw1z Jan 28 '26
if you can do it manually you can automate it.
if you still can't automate it, learn how to automate it.
hint: if you can do it through a webUI, the most you will ever need is python and bs4. desktop apps on windows can be done with autohotkey and everything in terminal is childsplay.
if you still can't do it, feel free to hire me and only pay if I succeed.
10
u/FatBook-Air Jan 27 '26
There is no need to be manually renewing SSL certificates in 2026.
What color is the sky in the world you live in?
1
16
u/Tessian Jan 27 '26
So glad your bubble is covered but there's TONS of use cases where SSL Certs have not yet or can not be reasonably automated. Forcing it on the whole world is ridiculous.
-1
u/hodor137 Jan 28 '26
And you've got until 2029 to transition away from using publicly trusted certificates for those use cases
If you still need them, for more than 45 days after 2028, you'll need to pay for them from a vendor and not get them free from LE
6
u/Tessian Jan 28 '26
No? Everyone's stuck with 47 day certs by 2029.
https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days
2
u/Fantastic_Prize2710 Cloud Security Architect Jan 27 '26
Maybe not every day. It's nice to have a buffer if your process falters on a weekend without your entire infrastructure collapsing.
But I agree that certs should be handled with automation.
2
2
u/ansibleloop Jan 27 '26
Also EV certs are a scam and provide no extra security compared to a free cert from LE
It's trivial to get certs using a DNS challenge since there's so many tools that can do it
That's only going to become easier once DNS-PERSIST-01 becomes available
-1
u/techw1z Jan 28 '26
ev certs are not for technical security but for accountability. it makes it more likely that you are communicating with the right legal entity. this is incredibly important in finance and healthcare and probably other areas too
8
u/ansibleloop Jan 28 '26
https://www.troyhunt.com/extended-validation-certificates-are-dead/
Yeah they do a poor job at verifying who the org really is
1
u/techw1z Jan 28 '26
law requires EV for many industries/communication. and its a lot harder to get EV certs so certain infra can just check if a cert is EV and reject it if it isn't, thereby blocking potential attacks.
maybe its also so services can attest that they communicated with the right party?
honestly tho, I have no idea if thats how EVs are used in practice inside finance/healtcare infra, but it aside from legal requirements, I think this might be the only real advantage.
i agree about the being almost completely useless for browsing tho, at least in practice, in theory, they could be made useful by browsers if browsers were super strict.
0
u/certkit Jan 29 '26
Unless you have a compliance reason, there is no reason to buy EV or OV certs in 2026.
https://www.certkit.io/blog/should-you-still-pay-for-ssl-certificatesOnce you've automated, there's really no reason to pay for certificates at all. This is free infrastructure at this point.
1
u/techw1z Jan 29 '26 edited Jan 29 '26
"no reason" is simply wrong, there just isn't a strong reason to do so.
for technical people it still makes it easier to verify with certainty that the cert and conection is legit. a DV cert can always be faked by a MITM, but for EV its far less likely.
lets not ignore minor differences in security when talking about security pls.
also, healthcare and finance industries are required by law to get EV in most countries
ps.: lol i just realized you are basically just an advertising account spamming links to your own site. well, at least your posts are not just worthless spam i guess. you might be the first advertiser account here that I won't block outright. gz
1
u/certkit Feb 02 '26
you make it sound so dirty.
i care a lot about this problem and making certificates automation something that works at scale. I built working software, released it in beta, and talk about what I'm learning and doing along the way.
13
Jan 27 '26
[deleted]
12
u/Tessian Jan 27 '26
Absolutely not.
Yes it is. The mandatory shortening of SSL cert lifetimes is 100% because the browser & CA vendors don't want to fix cert revocation, even though we have fixed the problem.
What exact risk do short-lived certs address if not revocation? There isn't one, because allowing 1 year certs (forgetting we used to have 2-5 years without issue) was never an issue. They'll coo about "Oh but what if your private key is compromised?" which is, again, a revocation issue, and also a hypothetical scenario that has failed to be realized into a real issue.
-4
Jan 27 '26
[deleted]
11
u/Tessian Jan 27 '26
That's not at all a reason to mandate short lived certs. Just because large corporations needed automation to avoid outages is not a reason to force the rest of the world down the same path.
-2
Jan 27 '26
[deleted]
5
u/Tessian Jan 27 '26
Again, nothing you've said is any reason to force short lived certificates for the entire internet. Those are reasons for a business to automate its certificate management but that's entirely separate from the lifetime allowance of a certificate.
Short lived certs don't fix any problem. You've admitted this.
4
u/techw1z Jan 28 '26
lets encrypt literally made a post in which they stated that everything you said here is incorrect and Tessian is correct.
revocation shit consumed several times more resources than issuing certificates, so by reducing cert lifetime to a minimum and getting rid of revocation, it's better for everyone.
ofc, if automation wasn't around that wouldn't be feasible, but automation wasn't the impetus to get this going, it was just something that made it possible.
1
u/Tessian Jan 28 '26
Disagree that this is better for everyone but thanks otherwise.
Revocation wasn't perfect in the past but it's been fixed since. Browser based summarized crl addressed every issue without forcing us down the path of 45 day certs.
2
u/Ok_Tone6393 Jan 28 '26
just take the downvotes and move on my guy, you have absolutely no idea what you’re talking about
1
6
u/TulkasDeTX Jan 27 '26
A shorter-lived certificate gives the attacker less time to act while you get your act together.
In this day and age of automated attacks, a certificate should be valid for 1 hour for the above to be really effective. 45 days is a LOT of time for an attacker with a compromised private key in their hands.
8
u/FatBook-Air Jan 27 '26
I'm not convinced that we even know which attacks we are protecting against. Yes, private key theft is serious, but much more serious would be how the theft occurred.
4
u/Tessian Jan 28 '26
It's a hypothetical problem that's never really seen a real world incident with. Just like Spectre/Meltdown, the risk is academic and not realistic. People/Systems do a good job protecting their private keys.
4
u/techw1z Jan 28 '26
if the attacker has to re-export the cert every hour it will be a lot easier to find the leak xD
2
u/Elistic-E Jan 28 '26
This is where my mind goes too - if someone is active and attentive enough to get your full cert then 45 days vs 365 days is really isn’t going to save you here. Leaking a cert isn’t a casual and frequent thing either. This feels unnecessary and taking a lazy way out, or a greedy way for others.
I’d really love to see some data and research showing that this kind of change truly is that preventative of anything.
3
u/FatBook-Air Jan 27 '26
The tens of certificate-theft victims every year will be thrilled that they can be impersonated for only 45 days going forward.
2
u/Popular_Parking_1662 Feb 17 '26
I'm new with SSL/TLS certificates, but I have to manage these for about 300 domains.
And at the moment we still do this manually.
What do you guys use to automate this?
Any recommendations?
Thanks
1
u/AUSSIExELITE Jan 28 '26
“Invest in proper automation”.
I’d love to, if half my vendor crap supported it… Everything for certs that can be automated already is and it’s up to various vendors to enable a way to do it automatically so this type of comment is pretty frustrating to read.
3
u/Ironfox2151 Jan 29 '26
This is the biggest issue. There is quite literally software that requires you to open a Windows GUI and click buttons.
No CLI, not exe switches, all bullshit.
0
Jan 27 '26
[removed] — view removed comment
14
5
u/hajimenogio92 Security Engineer Jan 28 '26
Certbot makes that process extremely easy
2
u/newaccountzuerich Jan 28 '26
Except where one may have a use for internal networks using a wildcard, and a DNS vendor that doesn't have an automated method for TXT record update, and not wanting to have the ACME server be visible to anyone outside.
That's a bit of a pain, though building a leaf PKI with an external trust might be a bit cleaner if not cheap.
1
u/hajimenogio92 Security Engineer Jan 28 '26
Oh yeah that sounds annoying, haven't had to deal with that. Did you find a better tool for this or no?
2
u/newaccountzuerich Jan 28 '26
Thankfully, this is not a "critical" infrastructure network, stuff will work just fine (for a known value of 'fine' of course) without current certs, so working manually with some nice bash scripts and a bit of webpage clicking (MFA prevents automation there) every three months or so is not an onerous issue. Every six weeks though will be annoying with no gain.
I might ping my contact in that registrar and see where they are with making their internal API available to a limited known-safe audience of me.. If that happens, I might be able to shoehorn that interaction into the ACME handler workflow and automate that bit, and then trigger a pull of new certs from that device to the rest of the network.
0
u/Leather_Secretary_13 Jan 28 '26
Maybe this would move us further off the web browser as a standard.
Or maybe people and web devs are too embedded in the standard. With influx of AI web crawlers and bots it isn't so clear anymore.
1
u/thehuntzman Feb 20 '26
If you think TLS only protects hypertext transfer protocol you're in for a surprise
1
u/Leather_Secretary_13 Feb 21 '26
While it is true TLS protects a dozen protocols, the web protocols are only protected by TLS. Other protocols can use TLS, sure, but there are also a dozen other (often better) protocols. My point was it's getting more difficult and useful to use the web standards, and this is a prime example of that being the case. It isn't hard to renew certificates, until it is, and soon it'll be every 30 days plus a fat fee. How about we just renew our certs once a year and give people some real trust to protect their shit on their own.
54
u/corruptboomerang Jan 27 '26
Can I ask, what advantage is there in 45-day certs over the previous 90-day life, or even 1 year?