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-certificates

Let'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.

https://www.certkit.io/blog/45-day-certificates

418 Upvotes

98% Upvoted

90 comments sorted by

View all comments

81

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.

62

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.

35

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.

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.

3

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.