The problem / use-case
Currently, Valkey loads TLS configuration even if certificates are expired or not yet valid. In this state:
- Incoming client connections fail during the TLS handshake with vague errors:
Server:
33725:M 30 Dec 2025 16:39:12.116 # Error accepting a client connection: error:0A000415:SSL routines::ssl/tls alert certificate expired (addr= laddr=127.0.0.1:6379)
Client:
Could not connect to Valkey at 127.0.0.1:6379: SSL_connect failed: certificate verify failed
- Server-side client certificates (used for mutual TLS in replication or cluster gossip) may also be invalid, causing replication or cluster communication to fail silently until connections are attempted:
Replica:
34229:S 30 Dec 2025 16:47:31.889 * Connecting to PRIMARY 127.0.0.1:6379
34229:S 30 Dec 2025 16:47:31.889 * PRIMARY <-> REPLICA sync started
34229:S 30 Dec 2025 16:47:31.889 * Non blocking connect for SYNC fired the event.
34229:S 30 Dec 2025 16:47:31.889 # Failed to read response from the server: Undefined error: 0
Primary:
34179:M 30 Dec 2025 16:47:37.946 # Error accepting a client connection: error:0A00010B:SSL routines::wrong version number (addr=127.0.0.1:58954 laddr=127.0.0.1:6379)
This delayed detection makes it difficult to diagnose TLS misconfigurations and can result in clusters starting “successfully” but being partially or fully unusable. Operators currently see vague runtime-only errors instead of a clear, immediate indication of certificate problems.
Proposed solution / feature
Fail TLS configuration immediately if any loaded certificate (server certificate, server-side client certificate, or CA certificate) is expired or not yet valid. Specifically:
- Validate the
notBefore and notAfter fields of all certificates when TLS contexts are created.
- If any certificate is invalid:
- Fail TLS configuration immediately.
- Log a clear message specifying which certificate is invalid and why.
- Apply this to all:
- Server certificates
tls-cert-file
- Server-side client certificates
tls-client-cert-file
- CA certificate file
tls-ca-cert-file
- CA certificate directory
tls-ca-cert-dir
- Apply to both:
- Server startup (initial TLS load)
- Runtime reload vis CONFIG SET
Goal:
Treat invalid certificates as configuration errors and prevent the server from running in an unusable state.
The problem / use-case
Currently, Valkey loads TLS configuration even if certificates are expired or not yet valid. In this state:
This delayed detection makes it difficult to diagnose TLS misconfigurations and can result in clusters starting “successfully” but being partially or fully unusable. Operators currently see vague runtime-only errors instead of a clear, immediate indication of certificate problems.
Proposed solution / feature
Fail TLS configuration immediately if any loaded certificate (server certificate, server-side client certificate, or CA certificate) is expired or not yet valid. Specifically:
notBeforeandnotAfterfields of all certificates when TLS contexts are created.tls-cert-filetls-client-cert-filetls-ca-cert-filetls-ca-cert-dirGoal:
Treat invalid certificates as configuration errors and prevent the server from running in an unusable state.