21–30 of 45 posts
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 o…
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.)
goes to make Caddy and CertMagic ACME clients even more complicated
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.
Earlier quoted context omitted.
> 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).