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

111–120 of 158 posts

Re: Decreasing Certificate Lifetimes to 45 Days

#111

Post by mcpherrinm »

parliament32 wrote: post #108

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 rat…

Note that renewing certificates is generally exempt from rate limits: https://letsencrypt.org/docs/rate-limits/#limit-exemptions-f...

We are working on further improvements to our rate limits, including adding more automation to how we adjust them. We're not ready to announce that yet.

We wanted to get this post out as soon as we'd decided on a timeline so everyone's on the same page here.

Re: Decreasing Certificate Lifetimes to 45 Days

#112

Post by parliament32 »

kassner wrote: post #104

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 "distributed websites" you mean multiple webservers for one FQDN? Usually TLS termination would happen higher up the stack than on the webservers themselves (reverse proxy, L7 load balancer, etc) and the cert(s) would live there. But if your infrastructure isn't that complicated then yes, the happy path is have each webserver independently handle its own certificate (but note your issuance rate limits, 5 certs per week for the exact same hostname[1]).

[1] https://letsencrypt.org/docs/rate-limits/#new-certificates-p...

Re: Decreasing Certificate Lifetimes to 45 Days

#113

Post by phasmantistes »

parliament32 wrote: post #108

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 rat…

Certificates that look like renewals -- for the same set of names, from the same account -- are exempt from rate limits. This means that renewing (for example) every 30 days instead of every 60 days will not cost any rate limit tokens or require any rate limit overrides.

Re: Decreasing Certificate Lifetimes to 45 Days

#114

Post by mcpherrinm »

flowerthoughts wrote: post #27
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.

I don't expect we'll ever remove the other validation methods, and certainly have no plans to do so.

There are pros and cons of various approaches.

Re: Decreasing Certificate Lifetimes to 45 Days

#115

Post by arccy »

nickf wrote: post #93
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?

Don't. Don't pin to public certificates. You're binding your app to third-party infrastructure beyond your control. Things change, and often. Note that pinning to a root or intermediate seems 'sensible' - but it isn't. Roots are going to start changing every couple of years. Issuing/intermediate CAs will be down to 6 months, and may even need to be randomised so when you request a new cert, there's no guarantee it'll…

This, have you thought about what happens when your CA needs to revoke your certificate because of some issue? can you even realistically re-pin before it's revoked (hours-days)?

Re: Decreasing Certificate Lifetimes to 45 Days

#116

Post by nickf »

j1elo wrote: post #38

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…

A certificate is a binding of a cryptographic key, along with an attestation of control of a DNS record(s) at a point in time. DNS changes frequently. The attestation needs to be refreshed much more frequently to ensure accuracy.

Re: Decreasing Certificate Lifetimes to 45 Days

#117

Post by patmorgan23 »

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…

All the enterprise software needs to do is create an API for configuring the certificate in the product. Then they can integrate Certbot or one of the many other ACME solutions, or let the customer do it (they are enterprises after all).

Re: Decreasing Certificate Lifetimes to 45 Days

#118

Post by kassner »

parliament32 wrote: post #112
kassner wrote: post #104

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 "distributed websites" you mean multiple webservers for one FQDN? Usually TLS termination would happen higher up the stack than on the webservers themselves (reverse proxy, L7 load balancer, etc) and the cert(s) would live there. But if your infrastructure isn't that complicated then yes, the happy path is have each webserver independently handle its own certificate (but note your issuance rate limits, 5 certs per…

In my case is multiple servers handling the same FQDN. They are load balanced via DNS or use DNS anycast in some situations. In any case, my server is the one terminating TLS.

Re: Decreasing Certificate Lifetimes to 45 Days

#119

Post by unsnap_biceps »

flowerthoughts wrote: post #27
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.

Accounts are many to one email address. Each of my servers have an individual account attached to the same email address.
Post reply on HN