[NEW] Add TLS Certificate Expiration Monitoring for Client Side TLS Connections #2910
Description
The problem/use-case that the feature addresses
Introduce TLS certificate expiration monitoring for client-side connections to Valkey. The goal is to provide early visibility and warnings when client-provided certificates are approaching expiration, allowing operators to prevent unexpected authentication failures and better manage certificate lifecycles.
This feature applies only to client certificates.
It does not enforce certificate rejection and does not apply to server certificates or cluster-internal TLS.
Description of the feature
Add lightweight monitoring for client-side certificate expiration during the TLS handshake.
Only valid certificates proceed to the expiration monitoring logic.
- Expiration Warning System
-
Extract and inspect the client certificate during TLS handshake.
-
Compute remaining validity (days until expiration).
-
If remaining days fall below a configurable threshold, emit a warning log.
- Metrics for Monitoring Systems
-
Emit a metric such as client_cert_days_until_expiry.
-
Integrate with Valkey’s existing INFO.
-
Support dashboards and alerting pipelines for certificate freshness.
No connection rejection will be implemented, the feature is strictly for observability.
Example config:
tls-client-cert-expiry-warn-threshold 10 # unit in days
INFO:
client_cert_min_days_until_expiry:5
client_cert_min_days_until_expiry:-1 # no client certificates observed
Alternatives you've considered
Using existing metrics such as connection failures
- Too late, provides no proactive signal before expiration.
Additional information
This feature is inspired by the TLS certificate expiration inspection logic in Apache Cassandra’s MutualTlsAuthenticator, which performs similar expiration checks and warning logs (without necessarily enforcing rejections).
Reference:
https://github.com/apache/cassandra/blob/a7a85c634a12d46fcd778709af77e35078ec60fc/src/java/org/apache/cassandra/auth/MutualTlsAuthenticator.java#L232
Valkey’s implementation would follow the same pattern: extracting certificate metadata at handshake time and generating warnings, while keeping behavior non-disruptive.
If this approach is approved, I will proceed with the implementation.