Context
Follow-up to #1338 / #1340.
HTTP/2 connections are long-lived and multiplexed. With keep_alive_while_idle(true) (the default), a healthy connection may never drop and reconnect, meaning the client_cert_resolver is only invoked on the initial handshake.
For users with short-lived certificates (e.g., Vault certs with 1–24h TTLs), rotation only takes effect when the connection happens to drop (server restart, network blip, keepalive timeout failure).
Proposal
Add a max_connection_lifetime: Option<Duration> to ConnectionOptions (or KeepAliveOptions) that forces periodic reconnection. For example, setting it to 12h would ensure new certificates are picked up at least every 12 hours.
This mirrors patterns in other gRPC clients:
- gRPC-Go has
MaxConnectionAge on the server side
- Java gRPC has
maxConnectionAge / maxConnectionAgeGrace
- The client-side equivalent would force a graceful channel recreation
Impact
This benefits all mTLS users, not just those using the dynamic cert resolver.
References
Context
Follow-up to #1338 / #1340.
HTTP/2 connections are long-lived and multiplexed. With
keep_alive_while_idle(true)(the default), a healthy connection may never drop and reconnect, meaning theclient_cert_resolveris only invoked on the initial handshake.For users with short-lived certificates (e.g., Vault certs with 1–24h TTLs), rotation only takes effect when the connection happens to drop (server restart, network blip, keepalive timeout failure).
Proposal
Add a
max_connection_lifetime: Option<Duration>toConnectionOptions(orKeepAliveOptions) that forces periodic reconnection. For example, setting it to 12h would ensure new certificates are picked up at least every 12 hours.This mirrors patterns in other gRPC clients:
MaxConnectionAgeon the server sidemaxConnectionAge/maxConnectionAgeGraceImpact
This benefits all mTLS users, not just those using the dynamic cert resolver.
References