[mholt]

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]

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]

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