Redis TLS client certificate rejected: which identity field does tls-auth-clients actually match?

The Short Answer

When tls-auth-clients yes is enabled, Redis does not perform identity matching against the Common Name (CN), Subject Alternative Name (SAN), IP address, or hostname. It only verifies that the client certificate is cryptographically valid and signed by the CA specified in tls-ca-cert-file.

In other words, tls-auth-clients is a requirement for authentication (proving the client is trusted by your CA), not authorization (verifying the client is a specific identity).

Likely Explanation vs. Confirmed Behavior

Confirmed Behavior

• Trust Chain Only: Redis uses the underlying TLS library (OpenSSL or wolfSSL) to validate the certificate chain. If the chain leads back to the provided CA file and the certificate is not expired, the handshake succeeds.
• No Peer-to-Identity Mapping: Redis does not natively compare the certificate's identity fields (CN/SAN) against the connecting peer's IP or a predefined whitelist.
• Consistency: This behavior is consistent across Redis 6.2 and 7.x, as well as between OpenSSL and wolfSSL builds, because the tls-auth-clients directive simply toggles the SSL_VERIFY_PEER (or equivalent) flag in the TLS library.

Likely Misconception

Users often expect mTLS to act as a firewall or identity-based access control list. However, in Redis, the TLS layer handles the encrypted tunnel and trust, while the ACL (Access Control List) system handles identity and permissions. Redis does not automatically map a certificate's CN to a specific Redis ACL user.

Verification Steps

To confirm your configuration is working as intended (rejecting untrusted clients), use these scoped commands:

1. Verify Successful Handshake:

   openssl s_client -connect your-redis-host:port -cert client.crt -key client.key -CAfile ca.crt

2. Verify Rejection of Untrusted CA:

   Attempt to connect using a certificate signed by a different, unrelated CA. The connection should be terminated during the handshake.

3. Check Server Logs:

   Monitor the Redis log file. A rejected certificate will typically trigger a TLS handshake failed error, though the logs will not specify which field (CN/SAN) caused the failure, as no field matching is performed.

Diagnostic Requirement

If you require the server to reject certificates based on a specific identity (e.g., only allowing client-01.example.com), please specify if you are using a TLS-terminating proxy (like HAProxy or Nginx) in front of Redis. If so, the identity matching must be configured at the proxy level via ssl-verify-client and header forwarding.