Hacker News Reader

Comment by cm2187 | Hacker News Reader

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?

View on HN

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.

Reply on news.ycombinator.com