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

141–150 of 158 posts

Re: Decreasing Certificate Lifetimes to 45 Days

#141

Post by basscomm »

wolrah wrote: post #139
basscomm wrote: post #128

Earlier quoted context omitted.

> the point is to force companies to automate renewal Cool. I'm a small-time webmaster with a couple of hobby sites with no more than a handful of visitors. Why do I need to set up automation to renew certs every 45 days, too?

For the same reasons as forcing companies to do it. 1. Revocation is a clusterfuck. Microsoft is currently failing to revoke tens of thousands of defective certificates for over seven months (the Baseline Requirements state that they should have been revoked within five days). Entrust was distrusted over repeated failures to revoke. Many TLS clients don't even bother to check revocation lists, or if they do they do i…

I'm talking about managing two certificates so I can share a static site with a handful of friends. Each one takes about 10 minutes a year to update.

Adding automation means I have to set up a process that I have to check up on at least once every 6.5 weeks to make sure it's still working.

Re: Decreasing Certificate Lifetimes to 45 Days

#142

Post by shizcakes »

toast0 wrote: post #59
ZeroConcerns wrote: post #53

Earlier quoted context omitted.

> other CAs aren't prohibitively priced Not if you look at the per-cert pricing, but if you factor in the cost of "dealing with incompetent sales" and "convincing accounting to keep the contract going", they absolutely are.

When I was working with Digicert a decade ago, it was expensive, but they also had knowledgable support and with a wildcard cert, they would issue all sorts of 'custom duplicates' by request that were super handy. No incompetent sales, but certainly you do need to make sure accounting will pay.

Unfortunately DigiCert has gone way downhill.

We pulled all of our business after they failed to renew a cert with 30d(!!!) notice and got themselves stuck in a loop of useless org re-validations.

They were completely unresponsive and wasted dozens of hours of our time trying to rectify the situation before we pulled the plug and switched everything to ACME. I still can’t believe we wasted so much time and money with them.

Re: Decreasing Certificate Lifetimes to 45 Days

#145

Post by iggldiggl »

Shish2k wrote: post #136
basscomm wrote: post #128

Earlier quoted context omitted.

> the point is to force companies to automate renewal Cool. I'm a small-time webmaster with a couple of hobby sites with no more than a handful of visitors. Why do I need to set up automation to renew certs every 45 days, too?

I'm a small time webmaster and I haven't "set up" any automation - for my shared-hosting sites, the host has it built in; and for my self-hosted sites, the web server has it built in

The problem is that this breaks down if you don't want to leak any obscure subdomains you might be using via CT-logs – shared hosting rarely supports DNS-based certificate renewals for wildcard certificates, and even less so for domains hosted by an external registrar.

(Even for a fully self-hosted system you'd still have to figure out how to interface the certificate renewal mechanism with your DNS provider, so not as easy to set up as individual certificates for each subdomain.)

Re: Decreasing Certificate Lifetimes to 45 Days

#146

Post by pona-a »

karel-3d wrote: post #120
xyzzy123 wrote: post #58

Earlier quoted context omitted.

Certificate per request

that's just OTR

OTR still has static identities, with DH used to ratchet the ephemeral keys. The comparison would be more like Signal ditching Safety Numbers and Registration Lock for hourly SMS verification of new independent keys with no successor signing.

There's a fundamental divide in what certificates mean: modern CAs view WebPKI as a fancy vantage point check--cryptographic session tickets that attest to the the actual root of trust, usually DNS. Short-lived certs (down to 10 minutes in Sigstore, 6 days trialed by LetsEncrypt) make perfect sense to them.

But DNS challenges are perfectly forgeable by whoever controls the DNS. This reduces authentication to "the CA says so" for 99% of users not running a private CA alongside the public one.

Transparency logs become impenetrable to human review, and even if you do monitor your log (most don't), you need a credible out-of-band identity to raise the alarm if compromised. The entire system becomes a heavier Convergence/DANE-like vantage point check, assuming log operators actually reverify the DNS challenges (I don't think one-time LetsEncrypt challenges are deterministic).

I think certificates should represent long-term cryptographic identity, unforgeable by your CA and registrar after issuance. The CA could issue a one-time attestation that my private root cert belongs to my domain, and when it changes, alert to the change of ownership.

Re: Decreasing Certificate Lifetimes to 45 Days

#147

Post by cedws »

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.

Re: Decreasing Certificate Lifetimes to 45 Days

#148

Post by baobun »

noman-land wrote: post #44
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…

Wouldn't it be better to bundle a script that generates a cert instead of the cert itself?

If I understand it right they bundle a publicly trusted shared cert and want to allow their users to get running on vanilla devices without having to provide a domain.

Re: Decreasing Certificate Lifetimes to 45 Days

#149

Post by wolrah »

basscomm wrote: post #141
wolrah wrote: post #139

Earlier quoted context omitted.

For the same reasons as forcing companies to do it. 1. Revocation is a clusterfuck. Microsoft is currently failing to revoke tens of thousands of defective certificates for over seven months (the Baseline Requirements state that they should have been revoked within five days). Entrust was distrusted over repeated failures to revoke. Many TLS clients don't even bother to check revocation lists, or if they do they do i…

I'm talking about managing two certificates so I can share a static site with a handful of friends. Each one takes about 10 minutes a year to update. Adding automation means I have to set up a process that I have to check up on at least once every 6.5 weeks to make sure it's still working.

> I'm talking about managing two certificates so I can share a static site with a handful of friends. Each one takes about 10 minutes a year to update.

The personal site I started with is one certificate for a static site that I use for basically the same thing. It took me 10 minutes to set up in 2016 and I haven't thought about it for a second since then. It just works.

> Adding automation means I have to set up a process that I have to check up on at least once every 6.5 weeks to make sure it's still working.

Assuming you're using a common automation package and not rolling your own it should be included. I personally use acme.sh which can be configured to use email, XMPP, or HTTP(S) requests with prebuilt templates for most popular webhooks, as well as supporting fully custom notification scripts. I get an email every time it attempts a renewal that tells me if it succeeded or failed. Again one-time setup, easy, did it once literally almost a decade ago and haven't had to think about it since. As I pointed out in my previous post I did once have two of my systems fail to renew, I was notified, and I fixed it within a few minutes of seeing the emails.

Let's Encrypt also used to send their own emails if a cert was expiring but they stopped doing that this year for a variety of reasons: https://letsencrypt.org/2025/01/22/ending-expiration-emails

Now that I'm actually thinking about the topic, these days for my work systems I have a platform that monitors for periodic updates and alerts me if they don't come in so I should probably reconfigure my notifications to use that instead of email and clean up my team's inboxes a bit by no longer needing to receive a couple dozen "everything's OK" mails every couple of months (or soon, couple of weeks).

Re: Decreasing Certificate Lifetimes to 45 Days

#150

Post by wolrah »

iggldiggl wrote: post #145
Shish2k wrote: post #136

Earlier quoted context omitted.

I'm a small time webmaster and I haven't "set up" any automation - for my shared-hosting sites, the host has it built in; and for my self-hosted sites, the web server has it built in

The problem is that this breaks down if you don't want to leak any obscure subdomains you might be using via CT-logs – shared hosting rarely supports DNS-based certificate renewals for wildcard certificates, and even less so for domains hosted by an external registrar. (Even for a fully self-hosted system you'd still have to figure out how to interface the certificate renewal mechanism with your DNS provider, so not…

> (Even for a fully self-hosted system you'd still have to figure out how to interface the certificate renewal mechanism with your DNS provider, so not as easy to set up as individual certificates for each subdomain.)

That's exactly what the new DNS-PERSIST-01 challenge is for, being able to authorize a specific system or set of systems to request certs for a given FQDN and optionally subdomains without having to give that system direct control over your DNS as the existing DNS-01 challenge requires.

Post reply on HN