Redis TLS client certificate hostname verification configuration missing

Answer

Redis currently does not offer a server‑side hostname verification flag. The tls-auth-clients setting only checks that the presented client certificate is signed by a trusted CA and that it is not expired. It deliberately leaves hostname matching to the client, as documented in the 7.2 release notes.

Adding a tls-verify-hostname option would provide the desired safety for multi‑tenant setups, but it would also be a breaking change for many existing deployments that rely on client‑side checks or that connect to Redis using a hostname that does not match the certificate’s SAN. In practice, this means a lot of real‑world clusters would experience connection failures immediately after the option is enabled.

Until a stable, backwards‑compatible server‑side feature is merged, operators should:

• Verify that tls-auth-clients=yes is enabled and that no tls-verify-hostname directive is present.
• Confirm that clients perform hostname verification themselves. For example, with OpenSSL:

openssl s_client -connect redis.example.com:6379 \
  -cert client.crt -key client.key \
  -servername redis.example.com

When the hostname in -servername does not match the certificate, the connection should fail with a verification error.

Why a Server‑Side Check Is Not Yet In Stable Redis

The Redis core team has explicitly stated that hostname verification is a client responsibility. The current tls-auth-clients implementation uses OpenSSL’s SSL_VERIFY_PEER flag, which validates chain and expiry but not hostnames. Adding a new flag would require a careful compatibility review and a clear deprecation path, which has not yet been agreed upon.

Impact on Existing Deployments

Deployments that:

• Use custom DNS names or reverse proxies that rewrite the hostname.
• Rely on client libraries that skip hostname checks (e.g., some legacy drivers).
• Have certificates issued for a different domain than the one used to reach Redis.

will experience connection failures if a server‑side check is enabled by default. The change would also introduce duplicate verification logic for those that already perform it client‑side, potentially adding latency.

Mitigation Strategies Until a Server‑Side Option Arrives

1. Client‑Side Verification: Ensure every client library in use has hostname validation enabled. Test with openssl s_client as shown above.
2. Reverse Proxy: Place a TLS‑terminating proxy (e.g., stunnel, HAProxy, Envoy) in front of Redis. Configure the proxy to enforce hostname checks before forwarding traffic to Redis. Example HAProxy snippet:

   frontend redis_front
     bind *:6379 ssl crt /etc/haproxy/redis.pem verify required
     mode tcp
     default_backend redis_back
   
   backend redis_back
     mode tcp
     server redis1 127.0.0.1:6380 check
   

3. Custom Scripts: If a proxy cannot be used, write a small wrapper that accepts TLS connections, performs hostname verification, and forwards the raw socket to Redis. This keeps the logic in one place and avoids modifying client code.
4. Certificate Naming Policy: Adopt a naming convention that guarantees the certificate’s SAN matches the hostname used by all clients. For example, issue certificates for redis.example.com and only allow that hostname in connection strings.

Next Steps

Operators should:

• Audit current client libraries for hostname verification support.
• Test the existing TLS setup with mismatched hostnames to confirm the gap.
• Plan for a migration path if and when a tls-verify-hostname directive is introduced in a future Redis release.

Until such a directive lands, the safest path is to enforce hostname checks on the client side or via an external TLS terminator.