by ZeroConcerns
3 subcomments
- 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") software products that simply won't get with the times (or get it wrong, like renewing the cert, but continuing to use the old one until something is manually restarted), and the countless IT departments that still don't support any kind of API for their internal domains...
by secret-noun
3 subcomments
- > 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...
by bravetraveler
1 subcomments
- The year is 2055, certificate lifetimes are measured in picoseconds. The Authority is still not pleased with your automation.
- 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?
- 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.
- > Acceptable behavior includes renewing certificates at approximately two thirds of the way through the current certificate’s lifetime.
So you can start renewing with 30d of lifetime remaining. You probably want to retry once or twice before alerting. So lets say 28d between alert and expiry.
That seems somewhat reasonable. But is basically the lower margin of what I consider so. I feel like I should be able to walk away from a system for a month with no urgent maintenance needed. 28d is really cutting it close. I think the previous 60d was generous but that is probably a good thing.
I really hope they don't try to make it shorter than this. Because I really don't want to worry about certificate expiry during a vacation.
Alternatively they could make the acceptable behaviour much higher. For example make 32d certificates but it is acceptable to start renewing them after 24h. Because I don't really care how often my automation renews them. What matters is the time frame between being alerted due to renewal failure and expiry.
- I’m maintaining a server with Let’s Encrypt certs for a B2B integration platform. Some partner systems still can’t just pin the CA and instead require a manual certificate update on their side. So every 90 days we do the same email ping-pong to get them to install the new cert — and now that window is getting cut in half.
Hopefully their software stack will be able to automate this by 2028.
- Cert lifetimes are such a burden. I wanted to provide pre-configured server examples of my WebRTC project, something that was download-and-run without any more prior knowledge (an important point), which users could access from their LAN e.g. to test the examples from their phones (not from the useless localhost exemption that exists for secure contexts), for which a self-signed cert embedded in the examples was fine. New users could run them, new concepts (such as security and certificate management in production apps) could be learned at an apropriate time.
Until web browsers started to believe that no, that was too much of a convenience, so now long expiration certs became rejected. What's the proposed solution from the "industry"? to run a whole automation pipeline just to update a file in each example folder every few months? bonkers. These should be static examples, no reason to having to update those any earlier than every few years, at most.
- I think next we should set maximum lifetime of public CAs to double of this value. Then we can also protect against failures there.
- How do people here deal with distributed websites? I’m currently issuing one certificate on my machine and then Ansible-ing it into all the servers. I could issue one certificate for each server, but then at any given time I’d have dozens of certs for the same domain, and all must be valid. That doesn’t sound right either.
by supriyo-biswas
1 subcomments
- The relevant section of the CA/Browser forum requirements that resulted in this change are here:
https://cabforum.org/working-groups/server/baseline-requirem...
by parliament32
2 subcomments
- One would hope they're also increasing rate limits along with this, but there's no indication of that yet.
> Up to 50 certificates can be issued per registered domain (or IPv4 address, or IPv6 /64 range) every 7 days. This is a global limit, and all new order requests, regardless of which account submits them, count towards this limit.
This is hard to deal with when you have a large number of subdomains and you'd rather (as per their recommendations) not issue SAN certificates with multiple subdomains on them.
by Snakes3727
2 subcomments
- 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.
by kyledrake
1 subcomments
- 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 of running into rate limit issues too.
- > DNS-PERSIST-01
Won't that introduce new security problems? Seems like a step back.
by mattbillenstein
0 subcomment
- fwiw, I host a free little service that can check certs once daily and email you if they're about to expire - https://ismycertexpired.com/check?domain=ismycertexpired.com
by silverliver
0 subcomment
- This is too short and the justification provided is flimsy at best.
I predict that normal people will began to get comfortable with ignoring SSL errors, even more than they already are. Perhaps we will see the proliferation of https-stripping proxies too.
- I’m imagining that xkcd meme about internet infrastructure and one of the thin blocks holding the whole thing up being LE.
Is there any good argument for short lifetimes? The only argument I know of is that short lifetimes are supposedly better in case the key gets compromised, but I disagree. If the key can be compromised once it can be compromised again when it renews; the underlying cause of compromise doesn’t go away. NIST stopped recommending forced password rotation for this reason, it’s pseudosecurity.
- I understand all of the benefits with regards to compromise and pushing automation, but I really hope they don't push the maximum lower.
It is already getting dangerously close to the duration of holiday freeze windows, compliance/audit enforced windows, etc.
Not to mention the undue bloat of CT logs.
- One way to protest against this would be to run our cert revoke&update script every hour.
- Not trying to diss on Letsencrypt, but I'm open to suggestions on paid cert providers.
by socrateswasone
0 subcomment
- [dead]
- > Decreasing Certificate Lifetimes to 45 Days
45 days ? So long ? Who needs so long living certificates ? A couple of miliseconds shall be enough. /s
- Translation: Like any large bureaucracy, the certificate industry sees its own growth as a moral virtue, and no limits to the burdens which it should be free to impose on the rest of society.
- This is all bullshit...
- "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."
I dont follow. Why? Why not an hour? A ssl failure is a very effective way to shut down a site.
"you should verify that your automation is compatible with certificates that have shorter validity periods.
To ensure your ACME client renews on time, we recommend using ACME Renewal Information (ARI). ARI is a feature we’ve introduced to help clients know when they need to renew their certificates. Consult your ACME client’s documentation on how to enable ARI, as it differs from client to client. If you are a client developer, check out this integration guide."
Oh that sounds wonderful. So every small site that took the LE bait needs expensive help to stay online.
Do they track and publish the sites they take down?
- Why not 7 days then
Hacker News