Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reliability via Automated Renewal Information

letsencrypt.org

Post reply on HN
Print view View original

11–20 of 45 posts

Re: Reliability via Automated Renewal Information

#11

Post by mcpherrinm »

cm2187 wrote: post #4
jaas wrote: post #3

Earlier quoted context omitted.

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)

Re: Reliability via Automated Renewal Information

#12

Post by WirelessGigabit »

cm2187 wrote: post #4
jaas wrote: post #3

Earlier quoted context omitted.

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.

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

Re: Reliability via Automated Renewal Information

#13

Post by dadrian »

detourdog wrote: post #5

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.

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

Re: Reliability via Automated Renewal Information

#14

Post by diarrhea »

tptacek wrote: post #9
detourdog wrote: post #5

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.

Re: Reliability via Automated Renewal Information

#15

Post by aranchelk »

detourdog wrote: post #5

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.

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.

Re: Reliability via Automated Renewal Information

#16

Post by lisper »

cm2187 wrote: post #2

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?

> 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.

Re: Reliability via Automated Renewal Information

#17

Post by schoen »

lisper wrote: post #16
cm2187 wrote: post #2

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?

> 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).

Re: Reliability via Automated Renewal Information

#18

Post by schoen »

detourdog wrote: post #5

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.

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...

Re: Reliability via Automated Renewal Information

#19

Post by cm2187 »

lisper wrote: post #16
cm2187 wrote: post #2

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?

> 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.

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

Re: Reliability via Automated Renewal Information

#20

Post by mcpherrinm »

diarrhea wrote: post #14
tptacek wrote: post #9

Earlier quoted context omitted.

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)

Post reply on HN