Reliability via Automated Renewal Information | Hacker News Reader

Reliability via Automated Renewal Information

letsencrypt.org

124 pointsdfern44 comments

This is... fine... but I wish we were pushing for shorter cert lifetimes rather than expanding infrastructure to support longer cert lifetimes and to band-aid revocation, which is broken anyway.

goes to make Caddy and CertMagic ACME clients even more complicated

The blog post mentions how this does help with the push for shorter cert lifetimes.

> ARI can be used to set subscribers up for success in terms of ideal renewal times in the event that Let’s Encrypt offers even shorter-lived certificates in the future.

That's not the same. That's saying "We issued a 90-day cert but now want it to be less than that." What I'm saying is "Issue 7 day certs."

I hope we can use ARI to trigger renewals as-if we had short lived certs, along that pathway. From a scale-up perspective of running the CA, that’s very useful.

Much of Let’s Encrypts engineering time has been spent on revocation infrastructure, and I don’t like it. I’d much rather issue 2.5 day certs than 2.5 day OCSP responses we need to serve with high availability.

I’m hoping in the near future we see a CA/B ballot and and associated root program changes allowing us to not run OCSP infrastructure for short-lived certs.

That’s the kick needed to support short-lived certs. Of course Caddy is one of the best implementations of TLS and certificate handling and is already ready for that world, but many other systems are going to have a much worse time. That’s a big concern, and it’ll take everyone a while to switch to Caddy to fix their busted manual processes :)

(I’m an employee of Let’s Encrypt but these opinions are my own)

Thanks for the feedback. Congrats on deploying a new feature to production!

I'll see about adding ARI to Caddy in the hopes that it will accelerate the transition to shorter-lived certs.

I don't see a standard 90 day certificate in the phrase "even shorter-lived certificates." If it was a 90 day certificate, it wouldn't be shorter-lived. It seems to me Let's Encrypt was referring to the possibility of exactly what you asked for, separately from revocation.

I don't understand why short duration IP, DNS, SSL lifetimes. I would think that IPs, DNSs, SSL, lifetimes that go unchanged would imply more stability thus better reputation.

TLS certificate revocation is an absolute clownfire and has been for 20+ years; short-duration certificates drastically mitigate the risk of stolen/misissued certificates.

I like step-ca's approach to this, which is passive revocation. Their certs last 24h. That diminishes the use and also need of active revocation and all the associated baggage dramatically: just don't renew. I imagine this will be the way forward, slowly but surely. It's just that the public internet is too fragile for 24h windows... yet.

24 hours is likely a little too short; I would expect to see 3-10 day long certificates in the near future. Google Trust Services is already doing 3-day IP address certs, and Firefox doesn't do any revocation checks for certificates under 10 days: https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox#S...

Let's Encrypt has always been focused on automation to make shorter certificates a reality, and ARI is part of that plan.

Shortening the lifetimes of the roots themselves is another thing that's coming, which is going to be harder for the world outside of auto-updating browsers to adopt.

(I work at Let's Encrypt, but this is my own opinion)

Is there a future where IP certs are single use, burn-on-read?

Yes.

We are aiming for that with Caddy. Starting with internal PKI. Caddy already has a built-in CA and ACME server, so it's just a matter of setting the lifetime to be very, very short.

However, ultimately this will require TLS clients to implement proper support. For example, we already see problems in some web browsers where their TLS logic doesn't account for short lifetimes (like < 1 hour) and so page navs result in security errors because the cert has expired when actually all they have to do is renegotiate the TLS connection. It's debatable whether a cert needs to stay valid through the entire connection lifetime or just for establishing the connection.

There is a performance penalty of doing this, of course, but for certain use cases it's acceptable.

Short certificate lifetimes (e.g. 1 hour) is not valid-for-a-single-request as the GP asked.

I'm having a real hard time wrapping my head around how Public Key Infrastructure could co-exist with every public key being a nonce. I'm not confident that it is impossible, but GP's question seems like an interesting theoretical/categorical question more than a hyperbolic "how short can lifetimes go?".

1 hour lifetimes sounds incredibly complicated to orchestrate on a practical level. Do you use a lot of short-lived ephemeral hosts (e.g. a swarm of docker images)? I'm not sure how 1 hour lifetimes wouldn't cause systemwide chaos in what I consider a "typical" microservice architecture.

> Short certificate lifetimes (e.g. 1 hour) is not valid-for-a-single-request as the GP asked.

I'm aware :)

Don't get hung up on the 1 hour figure. All I'm saying is that we already do < 1 hour quite often, and it doesn't work well because clients don't handle it well. I wasn't saying 1 hour is how you do ephemeral certs.

Caddy is capable of second-long certs if needed. With our current logic, it's easy enough to turn off certificate management and just make the certs ephemeral.

Early on I had the impression that short expiration probably made legacy CAs feel less threatened. Made Let’s Encrypt’s offering less comparable to those services —- prior to Let’s Encrypt, that business was basically:

Step 1) get my root cert accepted everywhere. Step 2) print money. Step 3) Try not to get hacked, print more money.

Some of the other replies have given the basic reasons; the original Let's Encrypt team was influenced by this paper, which stated some of those arguments more formally or academically:

https://www.ieee-security.org/TC/W2SP/2012/papers/w2sp12-fin...

Short TLS certificate lifetimes mean that the CA checks to ensure the certificate owner actually controls the DNS once every 3 months, so it's less likely someone will have a certificate for a domain they only had control of for a temporary period.

And I think the rationale is also to force people to automate the process which is a good thing.

I don't understand this sentiment. Once the process is automatic it won't be managed or monitored.

Well, even large companies do a crap job at managing and monitoring the renewal of certificates manually. There has been many occurences of large companies (including Microsoft or Linkedin) leaving some certificate expire.

Right and I don't expect them to manage an automatic process any better. I'm saying that there should be a form of trust for long standing stable environments.

You don't need to control the domain (only for wildcards), ability to serve under .well-known is enough.

You can mitigate things that go wrong quicker if the default lifetimes are shorter.

All of those are answers and possibly rationalizations. Seems to me an evil squatter could disrupt the system. The system is so automatic nobody needs to manage it.

I think this is a mistake they should be slowing down the system to gain reputation. Trying to keep pace with automatic spamming/hacking seems to be one possibility but longevity with no complaints should count for something.

I am not sure I understand the need for a reminder. Aren't all the certificate 90 days fixed? I am not sure how the default acmee client works (I built my own) but if you use it, by definition you already automated the renewal process on a schedule too. In which scenario do you need a reminder? Or is it when you don't have access to a scheduler but the acmee client still runs somehow automatically?

If Let's Encrypt needs to revoke the certificate prior to expiration (for compliance or any other reason) ARI can let a client know in advance of the revocation. The client can then renew early and avoid a disruption in service.

Clients that renew based on ARI can also help Let's Encrypt avoid disruptive load spikes since ARI signals can spread out renewals.

Ha ok, so it's specifically for revocations. Still a revocation would be done manually. It feels odd someone would revoke their certificate and not think about re-issuing a new one.

If a certificate was detected to be mis-issued after the fact, it may need to be revoked. And in fact many certificates may need to be revoked. This has happened to Let's Encrypt a few times already, and was the main motivation for this API. Some existing systems like the Caddy server use OCSP to detect if a cert is revoked and can renew immediately, but ARI allows allows a certificate to be reissued before the old one is revoked.

There are other related things that aren't specifically revocation: For example, certificates contain embedded Certificate Transparency timestamps from CT logs. If one or more of those logs fail, we might want to reissue those certificates before browsers distrust the logs.

(I work for Let's Encrypt)

> Some existing systems like the Caddy server use OCSP to detect if a cert is revoked and can renew immediately, but ARI allows allows a certificate to be reissued before the old one is revoked.

Hi Matthew :)

Caddy still serves a perfectly valid "GOOD" response from the OCSP responder while it renews the certificate, so the certificate is good as not-revoked until that OCSP staple expires.

(As we know, revocation is broken anyway. We should deprecate it for public PKI and go with short cert lifetimes instead.)

Any CA can revoke a certificate they issued without the subscriber being involved, so subscribers aren't necessarily revoking their own certs. When that happens ARI is a more efficient automated mechanism by which to let people know that a revocation is coming and they should renew.

When revoking a certificate it gives peace of mind that whatever system is using that certificate will pull a new one.

> by definition you already automated the renewal process on a schedule too

No, certbot does not run on a schedule by default. You have to set that up separately, and that can be non-trivial because you have to be able handle failures.

If you installed it with pip, it doesn't; if you installed it with an OS package or snap, it does (although it also didn't in that case for about the first year and a half of its existence, I think).

Can confirm, I have been using certbot+apache in production across multiple servers from Ubuntu apt repos since 18.04 in 2018 and scheduled auto-renewal is the default.

But if certbot doesn't run on schedule, presumably it will never connect to ARI either.

This is why Certbot should only be used temporarily to transition from legacy infrastructure. Ideally cert management (ACME client) needs to be baked into the server, like what Caddy does.

About the last thing security-wise that I want is for http server to control DNS record (which is required to have wildcard certs in LE)

When done properly, this is less of an attack vector than you think (certainly much less than a phishing email).

As well as revocation, I suppose it means if certificate lifetimes do change in future it can be done without having to upgrade/reconfigure all existing clients.

Perhaps someone using ACME for internal infrastructure may want shorter lifetimes, and this will make it easier.

Can anyone point to a working client implementation? It seems the API GET works but the POST to update the renewal isn't working for anyone as far as I can see.

Wouldn’t it be more efficient to get a list of renewable certificates/domains per account, instead of having to fetch renewal info separately for each certificate?

Loooking forwards to Caddy supporting this

Looks like Matt's already on it: https://news.ycombinator.com/item?id=35294522

Reply on news.ycombinator.com