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

31–40 of 45 posts

Re: Reliability via Automated Renewal Information

#31

Post by mholt »

witcH wrote: post #24
mcpherrinm wrote: post #20

Earlier quoted context omitted.

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…

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 There is a performance penalty of doing this, of course, but for certain use cases it's acceptable.

Re: Reliability via Automated Renewal Information

#32

Post by adql »

piperswe wrote: post #7
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.

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.

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

Re: Reliability via Automated Renewal Information

#33

Post by adql »

mholt wrote: post #29
lisper wrote: post #16

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.

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)

Re: Reliability via Automated Renewal Information

#34

Post by ccooffee »

mholt wrote: post #31
witcH wrote: post #24

Earlier quoted context omitted.

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 There is a performance penalty o…

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.

Re: Reliability via Automated Renewal Information

#35

Post by Ajedi32 »

mholt wrote: post #28

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.

Re: Reliability via Automated Renewal Information

#38

Post by mholt »

ccooffee wrote: post #34
mholt wrote: post #31

Earlier quoted context omitted.

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 There is a performance penalty o…

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 soun…

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

Re: Reliability via Automated Renewal Information

#39

Post by mholt »

Ajedi32 wrote: post #35
mholt wrote: post #28

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

Re: Reliability via Automated Renewal Information

#40

Post by mholt »

adql wrote: post #33
mholt wrote: post #29

Earlier quoted context omitted.

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).
Post reply on HN