Short-Lived Certificates Coming to Let's Encrypt

Short-Lived Certificates Coming to Let’s Encrypt

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.

This is an excellent idea.

Slashdot thread.

Tags: certificates, encryption

Posted on December 16, 2024 at 7:06 AM • 20 Comments

Comments

Impossibly Stupid • December 16, 2024 11:58 AM

I’m not saying it’s entirely a bad feature to support, but it’d be nice to hear what makes it “an excellent idea”. To me it smacks too much of mandating frequent password changes. What’s the actual use case/attack scenario that makes rapid-fire cert hopping a significant protection of my server traffic? Are key compromise events really some huge problem that I’ve simply been unaware of?

The 6 day target seems like a bad choice, too. Maybe it’s more flexible and you can schedule the refresh (at 90 days, it was never so pressing a deadline that I had to fuss with the timing), but I foresee many instances of issues that arise when an expiration/refresh falls on the weekends. I get that they probably want to spread the load out on their servers a bit, but we all still have human oversight over our security systems, and I wonder how this will play out when it meets the 5 day work week.

Dave • December 16, 2024 8:39 PM

An excellent idea? At beast it’s rounding up twice the usual number of suspects, but in practice it’s more of a really dumb idea. What’s going to happen is that you’re going to get a new cert + key almost every time you visit any site, which will be brilliant for phishers because you can no longer rely on any past history of the cert or key for the site. They can stand up a new phishing site with a never-seen-before key and it’ll look like a Let’s-Encrypt business-as-usual cert.

Clive Robinson • December 17, 2024 10:52 AM

@ ALL,

They say,

“This is a big upgrade for the security of the TLS ecosystem because it minimizes exposure time during a key compromise event.”

But as a matter of note discussions about shortening certificate lifetimes for many years, and step by step we’ve gone down from a quarter century down to now only just a year plus a pause for breath.

It would have been less if certain people had had their way.

And in fact some want rid of the current Certificate Authority issue all together.

Because all to often what is called “key compromise events” is not the fault of the system owners of the system a certificate is used on. But others in or attacking the certificate supply chain or other software supply chains.

For various reasons encryption systems are brittle / fragile and unexpected things can lead to a chain of events where security is not just gone in part but in whole, and it may not be obvious as to how it happened.

The latest example of alleged “enhanced built in security” going wrong this way is probably BadRAM CVE-2024-21944. It’s against the memory AMD’s “Secure Encrypted Virtualization”(SEV), “Trusted Execution Environment”(TEE) uses,

https://www.csoonline.com/article/3622917/amd-data-center-chips-vulnerable-to-revealing-data-through-badram-attack.html

In short it allows relatively easy access by low cost hardware to memory (sort of old school “Front Panel Access”).

But that memory content should also be encrypted, so limiting or stoping access to the protected plaintext if “Key Managment”(KeyMan) is sufficient.

Unfortunately not, there is a long known issue with stored ciphertext (encrypted plaintext). Where you do not ever need access to the plaintext just the ciphertexts on either side of a change in plaintext.

Known as a “replay attack” if you have access at that level you simply write the old ciphertext over the new ciphertext, and what was new is now old again.

The example the researchers give is changing the “balance” in an account, such that an expenditure from an account is removed (Surprisingly you can get away with just changing balances inside a computer for a very long time see UK Post Office Horizon’s scandal of malicious prosecutions).

However it’s not just finance data where this is an issue. Other data such as “Key Material”(KeyMat) can also be overwritten with new replaced by old.

So reenabling access that has been removed…

Karl F. • December 17, 2024 11:40 AM

I know you can have rolling certificates and announce already the next one, but this seems non-practical for especially e-mail servers. I could be mistaken though, just hoping we will never go to such short lifetimes as default. I have cert renawal automated of course, but 3 months give me more leisure in case a renewal job gets stuck. Looking forward to the future with many cert expired warnings.

Mark • December 17, 2024 6:50 PM

Wouldn’t this be made null if someone owned the server or was able to compromise the private cert than wouldn’t renewing often be pointless as they already have compromised the server. Especially if the admin has an auto renew and doesn’t handle it manually as it would be to much work load? I’m confounded by such a short length. Thanks

Clive Robinson • December 18, 2024 9:11 AM

For a view on this from a University bod,

https://utcc.utoronto.ca/~cks/space/blog/sysadmin/LetsEncryptRatelimitsAndUs

Martin • December 18, 2024 3:32 PM

Well then, LE service better not be down for more than six days or the internet will be in big trouble.

Paul Rain • December 18, 2024 9:44 PM

I assume this is being done because SSL issuers don’t like providing Certificate Revocation Lists or OCSP service.

As such, it ‘seems’ like a clever idea to avoid the problem of occasionally needing to revoke certificates by having them last an incredibly short amount of time. Steve Gibson isn’t always right, but when he’s right he’s right- and he’s most certainly right that this is absolute madness in a situation where a key point of failure like L.E. could be targeted for DDOS or other attacks.

Who? • December 19, 2024 7:35 AM

I differ to other opinions here. In my humble opinion, these short-lived certificates are not a bad idea themselves.

The problem is not the certificate being short or long-lived, the real issue here is the way our web services have been designed from the start. If you have a digital certificate signed by a trusted (from the point of view of our browser) authority you can supplant the identify of anyone you want. The only requirement is that certificate being valid for the domain you want to replace.

In other words, anyone controlling a certificate authority can emit certificates to replace any existing domain on the Internet not signed with a private root certificate. Can someone here think these certificate authorities have not been owned by means of NSLs from the U.S. Government for years?

Trust in web services should work in the same way it does on ssh(1) or pgp(1). Without a central authority signing them.

Just consider the nightmare it would be ssh(1) or pgp(1) accepting any certificate signed by a third party. Would you trust the machine you are connecting to? Would you trust the contents of a digitally-signed file if pgp(1) allows any certificate signed by a trusted third party on the Internet?

Web services have been designed to be user-friendly, so they are security-hostile by design. Those short-lived certificates in ssh(1) or pgp(1) would have been no security problem at all, just very annoying for other reasons (you need to acknowkedge them each time they change).

Sergio • December 22, 2024 10:28 AM

I’m also on the skeptical side of this trend because of the logistical challenges it brings, but there are some technological aspects that everyone should consider before building and opinion on this:

Underlying this approach is the ACME protocol, which makes it possible to automate the generation of certificates. There should not be a sysadmin manually reissuing certificates every six days.
The main argument I hear for this approach is that revocation as a paradigm failed. Maybe because owners didn’t react fast enough (or didn’t notice their key was compromised) or because the users didn’t check for revocation, or because both CRL and OCSP have their issues. If keys are short lived, revocation becomes unnecessary.
Another essential part of the equation is Certificate Transparency. The idea is that these databases keep track of all certificates ever issued, and service owners can set up alerts to detect if any certificate is issued for their domain. Again: I’m unsure of the practicality of this approach, but that’s how the model addresses the “what if someone creates a certificate on my behalf” concern.
On a related note: this trend would get rid of certificate pinning. The reasoning is that failure to update a pin would make a service fully unavailable. In this world, there would be no reason to rely on prior connections to decide whether to trust or not a given certificate.

I hope this helps guide the discussion.

Bill • December 23, 2024 1:23 PM

Not sure this is an improvement. Maybe we are solving a problem that doesn’t exist? The number of stolen, and then exploited, server certificates is pretty small. They certainly haven’t been in the news much.

As other commentators have noted, a DDoS attack on Let’s Encrypt would result (on average over the half-a-billion certificates issued by LE) in more than a million websites having invalid certificates each hour of the attack. The invalid cert totals would accumulate over the duration of the DDoS attack.

Maybe a reasonable alternative would be to permit users to invoke an option for longer durations?

Winter • December 24, 2024 3:48 AM

@Bill

Maybe we are solving a problem that doesn’t exist? The number of stolen, and then exploited, server certificates is pretty small.

It was quite a dissaster a decade ago. This included the complete loss of root of trust for the state of the Netherlands.

‘https://www.infosecinstitute.com/resources/cryptography/cybercrime-exploits-digital-certificates/

Security experts recognize 2011 as the worst year for certification authorities. The number of successful attacks against major companies reported during the year has no precedent, many of them had serious consequences.

As dependance on certificates grows for all kinds of communication channels and server authentication, I can see why LetsEncrypt tries to prevent another such disaster.

The security experts I do know applaud the move to short term certificates.

Steve • December 26, 2024 5:30 PM

Doesn’t this mean that a DDOS of Let’s Encrypt ACME servers lasting for only 3 days takes out 50% of the websites with LE certs?

Winter • December 27, 2024 10:36 AM

@Steve

Doesn’t this mean that a DDOS of Let’s Encrypt …

I assume Let’s Encrypt has made preparations against such a DDOD attack.

Could not find concrete info about their protection measures. So, maybe there is a reader who can inform us?

Kent Borg • December 27, 2024 2:18 PM

This seems a mistake.

Six-days is really short, it seems to me this puts renewals on a 24-hour or 48-hour schedule, because four or five days isn’t much time to fix something going wrong (or millions of things going wrong).

Which turns Let’s Encrypt into a single-point-of-failure for much of the internet.

I can see that this fixes some problems, but it looks like it makes scary new problems.

-kb

Clive Robinson • December 27, 2024 10:21 PM

@ Steve, ALL,

With regards,

“Doesn’t this mean that a DDOS of Let’s Encrypt ACME servers lasting for only 3 days takes out 50% of the websites with LE certs?”

No, but only because probability does not work in a straight line.

As a rough mental model it has to average towards any given outcome with random effects, so increases the time to get there (think doubles atleast).

See how a Quincunx or Gualton “nail board” builds up a “normal distribution”,

https://www.mathsisfun.com/data/quincunx.html

To get a feeling how “random” effects things.

Raven9 • December 28, 2024 11:18 AM

I have been using web browser that alerts me when a certificate is not the same as it was the last time I visited the site which at first seems like a good idea for security but since then I find almost every time I visit a Microsoft site, like outlook or live for example, I get an alert that the certificate is changed so now what?
When real world decisions depend on me receiving the email I am waiting for so I have only 2 choices and that reveals the security flaw of the whole system of certificates.
I either screw up my life by not continuing to log in and therefore don’t receiving the important email OR I ignore the warning and log in regardless.
Thecl major failing here is there no 3rd option so the average user, including me, ignores the warning about the certificate and logs in regardless thereby rendering all the supposed security completely obsolete.

Hendrik Visage • January 15, 2025 2:47 AM

To S or not to S, THAT is the HTTP!

The issue I have with HTTPS, is that the general view/brainwashing is that:
It’s encrypted, it is safe, so HTTPS makes everything safe

if we just encrypt the things that needs to be kept private, oh I’d be the front runner for httpS, but the way the search/etc. guys forced it down our throats, made me ask: What are THEY hiding?

Software updates for example: Look at the Debian mechanism, you have the trusted packager sign the package and it doesn’t get even looked/downloaded if there isnt a signature/publickey in your keystore for that package/repo.

Chris Drake • January 15, 2025 3:14 AM

Does this make ANY sense?

What live-hack lasts more than 6 days in the first place?

How often are TLS certificates comprised in the first place, and once they are, how often does it take more than 6 days for the revocation mechanisms to kick in?

If a TLS cert is compromised, the entire LE reissuance procedure is almost guaranteed to also be compromised in the same event.

This entire idea seems ill-conceived to start with, and incredibly fragile – it’s guaranteed to cause more problems than it solves: 6 days is woefully short for serious LE issues to be addressed if they occur, putting everyone at massive risk, and it’s often too short for sysadmins to take timely action when things break at our end (not every website has 24/7 devops – some of us take a week or two off from time-to-time!)

Nobody is going to reissue every 6 days – they’ll do it every day, of course… which ads a massive amount of downtime to everything that needs to be restarted during the process – and since it’s 6 days, we can no longer do that on Sunday nights…

Gene Hastings • January 15, 2025 12:01 PM

It’s one thing if this is an option. Users can do that if it’s useful to them.

If it’s mandatory (or even Apple’s proposal of 47 days) it’s an awful, wretched, miserable, nightmarish idea. I work in operations for a small team, and the notion that the time to respond to surprizes is to be shortened is anathema!

Never mind that there are things other than web servers that use TLS certificates (thanks to Steve Gibson for reminding me). Prominent among other things are MTAs, which do not have the well developed automation tools as web servers. And then there’s the proliferation of various web APIs that may or may not have the same facility or visibility to inspection as the web use case.

Whatever they are smoking, I hope there’s none of it left.

Certified graybeard operations crank.

Schneier on Security

Short-Lived Certificates Coming to Let’s Encrypt

Comments

Leave a comment Cancel reply