Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Decreasing Certificate Lifetimes to 45 Days

letsencrypt.org

Post reply on HN
Print view View original

21–30 of 158 posts

Re: Decreasing Certificate Lifetimes to 45 Days

#21

Post by ZeroConcerns »

crote wrote: post #14
ZeroConcerns wrote: post #2

I'm all for it -- it's hard to understate the extent to which LetsEncrypt has improved the WebPKI situation. Although the effective single-vendor situation isn't great, the "this is just something you only do via an automated API" approach is absolutely the right one. And certificate lifetimes measured in days work just fine with that. The only things that continue to amaze me are the number of (mostly "enterprise")…

It's not single-vendor. The ACME protocol is also supported by the likes of GlobalSign, Sectigo, and Digicert. You've got to remember that the reduction to a 45-day duration is industry-wide - driven by the browsers. Any CA not offering automated renewal (which in practice means ACME) is going to lose a lot of customers over the next few years.

Effectively single-vendor. I'm not aware of any ACME-compatible CAs that don't have pernicious limits on their free plans (and if there are, I'd love to hear!), and here in the EU we've even recently lost a rather big player...

Re: Decreasing Certificate Lifetimes to 45 Days

#22

Post by kyledrake »

0x1ceb00da wrote: post #9
kyledrake wrote: post #8

I'm sure this is for good reasons, but as someone that maintains a lot of ssl certificates, I'm not in love with this change. Sometimes things break with cert renewal, and it sometimes takes a chunk of time to detect and then sit down to properly fix those issues. This shortens the amount of time I will have to deal with that if it ever comes up (which is more often than you would expect), and increases the chances o…

What kind of issues do you usually face?

Without getting into specific stuff I've run into, automated stuff just, breaks.

This is a living organism with moving parts and a time limit - you update nginx with a change that breaks .well-known by accident, or upgrade to a new version of Ubuntu and suddenly some dependency isn't loading correctly, or that UUID generator you depended on to generate the name for the challenge doesn't get loaded, or certbot becomes obsolete because of some API change and you can't upgrade to the latest because the OS is older and you installed it from the package manager.

You eventually see it in your exception monitoring or when an ssl monitor detects the cert is about to expire. Then you have to drop that other urgent thing you needed to get done, come in and debug it, fix it, and re-issue all the certs at the rate limit allowed. That's assuming you have that monitoring - most sites probably don't.

If you detect that issue with 1/3 of the cert left, you will now have 15 days to figure that out instead of 30. If you can't finish it in time, or you don't learn about it in time, the site(s) hard fail on every web browser that visits and you've effectively got a full site outage until you repair it.

So you discover it's because of certbot not working with a new API change, and you can't upgrade with the package manager. Now you need to figure out how to compile it from source, but it doesn't like the python that is currently installed and now you need to install that from source, but that version of python breaks your python web app so you have to figure out how to migrate your app to that version of python before you can do that, and the programmer that can do that is on a week long whitewater rafting trip in Idaho.

Aside from all that, what happens if a hacker manages to wreck the let's encrypt infra so badly they need 2 weeks to get it back online? The internet archive was offline for weeks after a ddos attack. The cloudflare outage took one site of mine down for less than 10 minutes, it's not hard to imagine a much worse outage for the web here.

Re: Decreasing Certificate Lifetimes to 45 Days

#23

Post by raizer88 »

Since we're on the topic of certificates, my app (1M+ logins per day) uses certificate pinning with a cert that lasts for one year, because otherwise it would be a nightmare to roll the cert multiple times in production. But what would be the "modern" way to do smart and automated certificate pinning, now that short-lived certs are becoming the trend?

Re: Decreasing Certificate Lifetimes to 45 Days

#24

Post by micw »

redrove wrote: post #16
secret-noun wrote: post #4

> The key advantage of [DNS-PERSIST-01] is that the DNS TXT entry used to demonstrate control does not have to change every renewal. > We expect DNS-PERSIST-01 to be available in 2026 Very exciting! https://datatracker.ietf.org/doc/html/draft-sheurich-acme-dn...

Big news for both the lazy homelab admin that can set a TXT once and ultimately be more secure without spraying DNS Zone Edit tokens all over their infra AND for the poor enterprise folks that have to open a ticket and wait 3 weeks for a DNS record.

Very true. I have been in both roles.

Re: Decreasing Certificate Lifetimes to 45 Days

#25

Post by Snakes3727 »

As someone who works at a company who has to manage millions of SSL certificates for IoT devices in extremely terrible network situations I dread this.

One of the biggest issues is handling renewals at scale, and I hate it. Another increasingly frusturation is challenges via DNS are not quick.

Re: Decreasing Certificate Lifetimes to 45 Days

#26

Post by ZeroConcerns »

schmuckonwheels wrote: post #7
ZeroConcerns wrote: post #2

I'm all for it -- it's hard to understate the extent to which LetsEncrypt has improved the WebPKI situation. Although the effective single-vendor situation isn't great, the "this is just something you only do via an automated API" approach is absolutely the right one. And certificate lifetimes measured in days work just fine with that. The only things that continue to amaze me are the number of (mostly "enterprise")…

> The only things that continue to amaze me are the number of (mostly "enterprise") software products that simply won't get with the times Yeah, no one's rewriting a bunch of software to support automating a specific, internet-facing, sometimes-reliable CA. Yes it's ACME, a standard you say. A standard protocol with nonstop changing profile requirements at LE's whim. Who's going to keep updating the software every 3…

> I would like to see the metrics

Well, I could regale you with my anecdotes on how all my 'grab a LetsEncrypt cert on Docker deploy and whenever remaining lifetime goes below 75%' services have not had a single TLS-related outage in at least a year, and how we just had a multi-day meltdown caused by a load-bearing cert that everyone forgot about expiring, but I doubt you'll be interested.

I'm not here to take away your right to set up a few more 5-year+ internal CAs (or, hey, how about an entire self-signed hierarchy? can't be that hard...), and neither is LetsEncrypt. But on the Big Bad Internet (where Google is the leading cause of More Security, and LetsEncrypt is merely the leading vendor catering to that), things have moved on slightly.

Re: Decreasing Certificate Lifetimes to 45 Days

#27

Post by flowerthoughts »

secret-noun wrote: post #4

> The key advantage of [DNS-PERSIST-01] is that the DNS TXT entry used to demonstrate control does not have to change every renewal. > We expect DNS-PERSIST-01 to be available in 2026 Very exciting! https://datatracker.ietf.org/doc/html/draft-sheurich-acme-dn...

This replaces an anonymous token with a LetsEncrypt account identifier in DNS. As long as accounts are not 1:1 to humans, that seems fine. But I hope they keep the other challenges.

I really would have felt better with a random token that was tied to the account, rather than the account number itself. The CA side can of course decide to implement it either way , but all examples are about the account ID.

Re: Decreasing Certificate Lifetimes to 45 Days

#28

Post by jrjfjgkrj »

raizer88 wrote: post #23

Since we're on the topic of certificates, my app (1M+ logins per day) uses certificate pinning with a cert that lasts for one year, because otherwise it would be a nightmare to roll the cert multiple times in production. But what would be the "modern" way to do smart and automated certificate pinning, now that short-lived certs are becoming the trend?

your app would download the new certificate from an endpoint which returns the new certificate signed with the old one that you currently pin?

Re: Decreasing Certificate Lifetimes to 45 Days

#29

Post by Grikbdl »

raizer88 wrote: post #23

Since we're on the topic of certificates, my app (1M+ logins per day) uses certificate pinning with a cert that lasts for one year, because otherwise it would be a nightmare to roll the cert multiple times in production. But what would be the "modern" way to do smart and automated certificate pinning, now that short-lived certs are becoming the trend?

Pin the cert authority instead?

Re: Decreasing Certificate Lifetimes to 45 Days

#30

Post by arjie »

Forgetting the obvious security advantage for the moment, I've found this to actually be convenient that the lifetimes are rather short. I'm not disciplined when it comes to setting up my homelab projects, so in the past sometimes I'd just LE it and then worry about it when renewal failed. My family is the only consumer so who cares.

But then they set some shorter lifetime, and I was forced to set up automation and now I've gotten a way of doing it and it's pretty easy to do. So now I either `cloudflared` or make sure certbot is doing its thing.

Perhaps if they'd made that more inconvenient I would have started using Caddy or Traefik instead of my good old trusty nginx knowledge.

Post reply on HN