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.
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.
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?
I’m sorry but if you aren’t using automated renewals then you are not using let’s encrypt the way it’s intended to be used. You should take this as an opportunity to get that set up.
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?
I still think the web would have been better off if certificates were signed and part of a web of trust like in GPG/PGP. It wouldn’t stop sites from using trusted CAs to increase their trust levels with browsers, but it would mean that tiny websites wouldn’t need to go through layers of mandatory bullshit and inconvenience. Also means that key signers could have meaningful business relationships rather than being some random CA that nobody has a clue about.
3 letter organisms: NSA - CIA. People tend to think that’s a conspiracy theory… Even though we have so many real life examples about how the US and the 3 letters agencies have their hands all over the web and privacy and encryption is just a wet dream !
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.
Are you not using LE certbot to handle renewals? I can’t even imagine doing this manually.
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.
One reason for the short certs is to push faster adoption of new technology. Yes that’s about new cryptography in the certs but if you still change all your certs by hand maybe you need to be forced …
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). If it is unsafe by design, the design flaw should be fixed, no?
Or am I missing the point?
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.
