Let's Encrypt Announces New-Certificate-Every-6-Days Offering (letsencrypt.org) 60
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: (Score:1)
Re: (Score:3)
the client gets to point at one or more CA they have trusted
Pardon me for correcting your English, but a client is not a "they". A client is an "it".
The client can identify as whatever they want, you insensitive clod!
Re: (Score:2)
With multi-threaded browsers, who even knows anymore...
Thanks for posting the story (Score:5, 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
Re: (Score:2)
OMG, Where is DANE when you need it? (Score:5, 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:OMG, Where is DANE when you need it? (Score:5, Informative)
Re: (Score:3)
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:2)
I will be surprised if more than five people sign up for this when they release it, and I will be even more surprised if more than two of them are still using it after six months, ...
I'm in complete agreement with every point you made... except this statement. If you'd said something like "more than five serious enterprises", then I'd agree - but I bet a whole bunch of the "I run a web server at home on my Linux box, using a hand-tuned nginx daemon" crowd will do it and keep doing it - because it's their hobby, and they love spending time on stuff like this.
Problem is, the people who've been pushing for shorter certificates (those "five enterprises" mentioned earlier - which includes A*
Re: (Score:2)
It won't even be just the hobbyists. Worse will be the same "checkbox security" Security "Engineers" who mindlessly require/required 12 character passwords with caps,symbols,numbers,lowercase and insist(ed) that they have to be changed every 30 days until NIST finally said "stop it!"
The same ones who demand updates whenever a CVE comes out w/o the slightest understanding of how said library is used or capacity to examine the risk posed by the vulnerability in context of the system it's being used in.
Ther
Re: (Score:2)
Of course, the fact that we even have
Re: (Score:3)
Let's Encrypt is ending OCSP support in 2025 [letsencrypt.org]
Re: (Score:2)
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.
Re: OMG, Where is DANE when you need it? (Score:2)
DNSSEC is good for stopping MITM attacks on DNS as well. It's entirely possible browser vendors have been pressured not to use DNSSEC by those entities who do DNS MITM.
Re: (Score:2)
This nonesense was (likely) spearheaded by Amazon. AWS has a $400/month CA which can make certs as long as you like. Alternatively, use the $50/month one, but your certs only last a week. Oh, and in both cases, you pay for each cert you issue. The $50/month service starts to rack up some decent money if you create and destroy servers with any regularity. Given it doesn't really cost AWS anything extra to actually issue a cert, it's got to be a nice earner for them.
Weekly certs are workable, but it requires
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:5, 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)
... or more often than not its on the bosses credit card, the boss refuses to delegate, ignores the emails and then is on a mental-health holiday when the shit hits the fan.
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
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 reboot servers frequently without knowing. - They are the ones most likely to have their server come up problem free when something *does* go wrong forcing a reboot.
That's kind of true for manual tasks, but it's only half the story, at best. Individual systems that get regular maintenance are actually way more likely to not come back up than systems that get infrequent maintenance. What makes nobody notice is that that they have enough redundancy that everything appears to still work even when one third of the clusters sh** the bed. And what frequent updates does is force automation for what otherwise might be a manual task, which at least theoretically should incre
Re: (Score:2)
What makes nobody notice is that that they have enough redundancy that everything appears to still work even when one third of the clusters sh** the bed.
That is exactly my point. What do you think your end user cares about here? No one gives a shit if a system admin is having a bad day, not the customer, not your manager, they give a shit if the website is down and the customer can't complete their checkout. There's a reason I used both the terms servers and systems in my post. Systems are what people care about, how much redundancy is setup underneath is not relevant to anyone other than the person tasked with keeping the system up.
Re: (Score:2)
What makes nobody notice is that that they have enough redundancy that everything appears to still work even when one third of the clusters sh** the bed.
That is exactly my point. What do you think your end user cares about here? No one gives a shit if a system admin is having a bad day, not the customer, not your manager, they give a shit if the website is down and the customer can't complete their checkout. There's a reason I used both the terms servers and systems in my post. Systems are what people care about, how much redundancy is setup underneath is not relevant to anyone other than the person tasked with keeping the system up.
Yes, I realize that. My point is that even though the systems as a whole stay up longer, it is all the other stuff that frequent cert changes force (e.g. automation) that makes them stay up longer, and that the act of changing certs more often in and of itself almost certainly actually reduces overall stability, because it means more clusters are going to misbehave more often, and the resulting errors *can* affect users if they result in a cluster actually failing (e.g. if the cert gets deleted and not rep
Re: (Score:2)
On the plus side, if it fails in 6 days it's more likely to be noticed then if it fails in 6 years, long after the product was abandoned.
Ridiculous (Score:4, Insightful)
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:3, 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.
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.
Know any good free or cheap basic domain validation CAs with at least a one-year expiration period? I've been on LetsEncrypt since the StartSSL compromise forced me off of there, and I've been looking for a good alternative ever since, precisely because the whole use of DNS for validation has been so problematic on so many occasions.
Re: (Score:2)
nope, this is a homeassistant instance, so I just signed up for cacert, and loaded the new root into devices.
Re: (Score:2)
How many certificates per day? (Score:4, Insightful)
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:2, 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 dif
Six? (Score:4, Insightful)
Why not seven? Or the incoming cert is guaranteed to collide with Patch Tuesday periodically.
Re: Six? (Score:3)
IMHO seven is the magic number. Seven little squirrels, twirling on a branch, eating chestnuts on my uncle's ranch. Seven, man. Seven.
If only we had a revocation mechanism (Score:3)
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)
Re: (Score:3)
I renew my 90 day certs every 7 days, keeps the sliding window happening and its all scripted, I need not touch a thing.
DV simply needs to die (Score:2)
Trust should flow from the naming system rather than a redundant parallel system with insane dependencies on insecure unauthenticated indications of control.
DV simply doesn't deserve to continue to exist. It increases the cost and decreases the security of the Internet for no reason.
Re: (Score:2)
Remember this is an issue of trust, and there are conflicting definitions of trust all over the place. (It's not just Hackers vs. Everyone else.) There's also those who could care less until their carelessness bites them in the ass to consider as well.
Re: (Score:2)
But who controls the naming system?
The same cast of characters who manage the domain hierarchy today. When you pay your dues for domain registration it should include the means of proving that same relationship to third parties.
Remember this is an issue of trust, and there are conflicting definitions of trust all over the place.
Not sure what is meant with conflicting definitions. The question I would pose is would you rather:
A. The entity that grants you control over your domain name do the signing.
B. Any of a group of separate redundant entities each with full power over the entire naming hierarchy use insecure indications from insecure
Still plenty of systems out there ... (Score:2)
Still plenty of systems out there that do not, and never will support Let's Encrypt certs with Certbot (et al).
Until every device, every server system supports Certbot, then no, this can not be a thing. Way too much manual working. And not just 1 or two servers, but dozens or hundreds. Yes, they are internal systems, no you can't just stick a proxy/load balancer in front of them. Yes, they are behind a VPN and not exposed to the internet.
Yes, you can run an internal PKI server, no, it's getting harder to ha
Let's Encrypt & the NSA (Score:2)
The NSA must find Let's Encrypt a very tempting target -- compromise a key and slurp up lots of encrypted traffic. Since all of the LE infrastructure is on USA soil where USA laws are enforcible (with secrecy clauses) I would be surprised if this had not happened and LE is not allowed to talk about it.
Has anybody got any better knowledge than my speculation ?
Re: (Score:2)
An upvote for you.
Time the LE certs were taken out of the US. And not in the UK. And typically, where the world gets divided into "for-us" or "against-us" camps, almost no neutral "take the good and resist the bad" reasonable and neutral, able to ignore US/China/Russia pressure, place for them to reside.
They shouldn't rely on donations (Score:2)
There are many, many Fortune 1000 companies that use LetsEncrypt and provide nothing to support the service.
LetsEncrypt could easily change their TOS to be revenue capped. If you have more than 100M in revenue, you need to pay.
Re: (Score:1)
You're not kidding. Did anyone notice that the Whitehouse.gov uses a let's encrypt cert?