[HN Gopher] Reliability via Automated Renewal Information
___________________________________________________________________
Reliability via Automated Renewal Information
Author : dfern
Score : 104 points
Date : 2023-03-24 16:54 UTC (6 hours ago)
(HTM) web link (letsencrypt.org)
(TXT) w3m dump (letsencrypt.org)
| dochtman wrote:
| 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?
| mholt wrote:
| 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_
| Ajedi32 wrote:
| 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.
| mholt wrote:
| 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."
| jacooper wrote:
| Loooking forwards to Caddy supporting this
| proactivesvcs wrote:
| Looks like Matt's already on it:
| https://news.ycombinator.com/item?id=35294522
| detourdog wrote:
| 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.
| dadrian wrote:
| You can mitigate things that go wrong quicker if the default
| lifetimes are shorter.
| detourdog wrote:
| 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.
| detourdog wrote:
| 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.
| piperswe wrote:
| 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.
| adql wrote:
| You don't need to control the domain (only for wildcards),
| ability to serve under .well-known is enough.
| cm2187 wrote:
| And I think the rationale is also to force people to automate
| the process which is a good thing.
| detourdog wrote:
| I don't understand this sentiment. Once the process is
| automatic it won't be managed or monitored.
| cm2187 wrote:
| 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.
| detourdog wrote:
| 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.
| schoen wrote:
| 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...
| aranchelk wrote:
| 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.
| tptacek wrote:
| TLS certificate revocation is an absolute clownfire and has
| been for 20+ years; short-duration certificates drastically
| mitigate the risk of stolen/misissued certificates.
| diarrhea wrote:
| 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.
| mcpherrinm wrote:
| 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_Check
| ing_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)
| witcH wrote:
| Is there a future where IP certs are single use, burn-on-
| read?
| mholt wrote:
| 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.
| ccooffee wrote:
| 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.
| mholt wrote:
| > 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.
| cm2187 wrote:
| 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?
| advisedwang wrote:
| 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.
| lisper wrote:
| > 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.
| mholt wrote:
| 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.
| adql wrote:
| 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)
| mholt wrote:
| When done properly, this is less of an attack vector than
| you think (certainly much less than a phishing email).
| schoen wrote:
| 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).
| tomxor wrote:
| 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.
| cm2187 wrote:
| But if certbot doesn't run on schedule, presumably it will
| never connect to ARI either.
| jaas wrote:
| 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.
| cm2187 wrote:
| 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.
| jaas wrote:
| 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.
| mcpherrinm wrote:
| 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)
| mholt wrote:
| > 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.)
| WirelessGigabit wrote:
| When revoking a certificate it gives peace of mind that
| whatever system is using that certificate will pull a new
| one.
___________________________________________________________________
(page generated 2023-03-24 23:00 UTC)