Let's Encrypt Announces New-Certificate-Every-6-Days Offering (letsencrypt.org) 28
The non-profit, free certificate authority Let's Encrypt shared some news from their executive director as they approach their 10th anniversary in 2025:
Internally things have changed dramatically from what they looked like ten years ago, but outwardly our service hasn't changed much since launch. That's because the vision we had for how best to do our job remains as powerful today as it ever was: free 90-day TLS certificates via an automated API. Pretty much as many as you need. More than 500,000,000 websites benefit from this offering today, and the vast majority of the web is encrypted.
Our longstanding offering won't fundamentally change next year, but we are going to introduce a new offering that's a big shift from anything we've done before — short-lived certificates. Specifically, certificates with a lifetime of six days. This is a big upgrade for the security of the TLS ecosystem because it minimizes exposure time during a key compromise event.
Because we've done so much to encourage automation over the past decade, most of our subscribers aren't going to have to do much in order to switch to shorter lived certificates. We, on the other hand, are going to have to think about the possibility that we will need to issue 20x as many certificates as we do now. It's not inconceivable that at some point in our next decade we may need to be prepared to issue 100,000,000 certificates per day. That sounds sort of nuts to me today, but issuing 5,000,000 certificates per day would have sounded crazy to me ten years ago... It was hard to build Let's Encrypt. It was difficult to scale it to serve half a billion websites...
Charitable contributions from people like you and organizations around the world make this stuff possible. Since 2015, tens of thousands of people have donated. They've made a case for corporate sponsorship, given through their Donor-Advised Funds, or set up recurring donations, sometimes to give $3 a month. That's all added up to millions of dollars that we've used to change the Internet for nearly everyone using it.
Thanks to long-time Slashdot reader rastos1 for sharing the news.
Our longstanding offering won't fundamentally change next year, but we are going to introduce a new offering that's a big shift from anything we've done before — short-lived certificates. Specifically, certificates with a lifetime of six days. This is a big upgrade for the security of the TLS ecosystem because it minimizes exposure time during a key compromise event.
Because we've done so much to encourage automation over the past decade, most of our subscribers aren't going to have to do much in order to switch to shorter lived certificates. We, on the other hand, are going to have to think about the possibility that we will need to issue 20x as many certificates as we do now. It's not inconceivable that at some point in our next decade we may need to be prepared to issue 100,000,000 certificates per day. That sounds sort of nuts to me today, but issuing 5,000,000 certificates per day would have sounded crazy to me ten years ago... It was hard to build Let's Encrypt. It was difficult to scale it to serve half a billion websites...
Charitable contributions from people like you and organizations around the world make this stuff possible. Since 2015, tens of thousands of people have donated. They've made a case for corporate sponsorship, given through their Donor-Advised Funds, or set up recurring donations, sometimes to give $3 a month. That's all added up to millions of dollars that we've used to change the Internet for nearly everyone using it.
Thanks to long-time Slashdot reader rastos1 for sharing the news.
Next step, new certificate for every TLS request! (Score:3)
That will *really* beef up security!
Re: Next step, new certificate for every TLS reque (Score:1)
You jest but ideally you would do TLS with a CA that the client trusts, meaning the client gets to point at one or more CA they have trusted and then the server gets a signed certificate from them for the duration of the session.
Re: (Score:1)
Thanks for posting the story (Score:4, Interesting)
I've use Let's Encrypt certs for years and never donated. [shame]
But the article reminded me of my 'civic duty' and I've now donated.
Thanks
OMG, Where is DANE when you need it? (Score:4, Insightful)
I've never been much of a fan of DNSSEC, but nonsense like this make me hope someone will see some sense and finally make DANE a reality to take TLS away from chutzpahs like this.
When is the last time a TLS certificate was compromised in a way that would make this even marginally warranted? The far more likely scenario is that a whole server will be compromised, in which case its LetsEncrypt client key is as compromised as the rest. Besides a few much publicized failures, mostly of CAs, there is nothing that warrants this level of client hoop-jumping and waste.
Re: (Score:1)
Re: (Score:3)
Re: (Score:2)
Revocation in a PKI is not a solved problem. There are several ways to do it, and they each have drawbacks. That's because we want the cake (offline verification) and eat it too (online verification).
In practice, if the duration were 6 days instead of 90 days, the various random problems I've had with LetsEncrypt when changing ISPs, changing registrars, etc. would have all resulted in downtime, where with 90 days, I usually got notification after 60 days that the renewals were down, and it usually took most of those remaining 30 days for me to find the time to actually deal with the problem.
I can't imagine why anyone in their right minds would think that this is a good idea.
Offline verification isn't ac
Re: (Score:3)
Something similar to DANE was available years ago:
FreeS/WAN's opportunistic encryption. It used public keys found in the site's DNS to encrypt.
And an additional risk (Score:4, Insightful)
The more often a cert is replaced, the more devastating an attack on the replacement mechanism becomes. I do get that cert revocation does not work and cannot be fixed (the history of trying to do so is a sequence of hilarious failures), so short-lived certs is all we have. But they come with their own risks and are, at best, a band-aid.
More chance for failure (Score:4, Insightful)
Re:More chance for failure (Score:4, Insightful)
If something goes terribly wrong, most of the internet would collapse in 6 days. I've already seen major sites and software get hit with certificate expiries.
Although, more often than not, it was due to some process (manual or semi-automated) that was not validated in an appropriate time frame (they only did it once a year or once every few years, and in that time-frame "stuff" happens, including redundancies that eliminate key personnel). If your certs expire every 6 days you are going to strive to get that process working well.
Re:More chance for failure (Score:5, Insightful)
Re: (Score:2)
While the risk is very well the problem with major sites is the opposite. The likelihood of errors in process increase with a rarity of a maintenance event. This has nothing to do with TLS by the way, you can find references to this in reliability textbooks, as well as human behavioural studies. Similar to making it a civic duty to call people who masturbate over their server's uptime idiots, and instead promoting administrators who are capable of setting up systems in such a way that they are able to reboo
Ridiculous (Score:3)
Certificate expiry and renewal failures are a few orders of magnitude, maybe a dozen, above proven in-the-wild compromised TLS key attacks. There is a point where the tradeoff between security and reliability becomes far too bad to be worth it, and this tradeoff was already pretty bad with annual renewals. Now we see this insanity playing out.
No. No more short lived certificates. Just stop.
Automation (Score:2, Interesting)
I have used Let's Encrypt in the past, but don't anymore. While the service is useful, the automated renewal does not work when you use nonstandard ports and there is no workaround except to renew each certificate manually. It was enough of a hassle to do that every 90 days. I can't imagine what a nightmare would be to do it every 6 days.
6 day work week for you no change m-f and each s i (Score:2)
6 day work week for you no change m-f and each s is the renew day.
Also no OT pay for that day to be on call.
Re: (Score:2)
Do you want to be the person who tells my admin that he can never go on a cross country bicycle trip again. Well, he can. But he'd better pedal his ass off to get back here by Monday.
Re: (Score:2)
agreed, especially when using the DNS challenge I kept getting issues requiring manual intervention.
system not internet facing, but a single https service available using sni tunneling through another system. This is a major PITA usecase for letsencrypt.
How many certificates per day? (Score:5, Interesting)
issue 100,000,000 certificates per day.
I think more like 300,000,000 certificates per day. With a 6-day expiry, I'm not going to renew every 5 days, I am going to renew every day, just in case something goes wrong. Plenty of other sites are going to do the same.
Wrong approach. (Score:3, Interesting)
A much better system would surely be to generate a Class III certificate suitable for a sub-certificate authority that expires maybe once every two years, and then generate short-lived certificates (3 months seems fine) using the Class III cert to sign with.
The first reason for this is that the renewal system is your vulnerability. If the renewal system is distributed this way, you'd have to break it for every user independently.
The second reason is that you can use GPG's recommended practice of using a different key for each recipient, so you now have to break every senter/recipient pair independently, too.
However, if you run all connections between two nodes over an encrypted tunnel, an attacker can't distinguish a renewal from any other operation. The traffic is indistinguishable.
That's the beauty of encrypted tunnels vs Just an encrypted packet - attackers have to attack the lot, not just the bits they want.
Six? (Score:3)
Why not seven? Or the incoming cert is guaranteed to collide with Patch Tuesday periodically.
If only we had a revocation mechanism (Score:2)
Why didn't any smart people think of this!
Note this post is sarcastic, smart people did think of this. Rather than placing an amazing burden on automation and administration why not fix the damn certificate revocation mechanism instead. This is precisely the case it was designed for.
Go ahead and offer it. (Score:2)