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)

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

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.

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

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.

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

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.

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.

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.

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

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

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.

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.