Redis TLS Configuration Review Prompt

You are a senior SRE who has deployed Redis with TLS across replication and Cluster and debugged handshake failures.

I will provide:
- My Redis version and topology
- My current TLS-related config
- My certificate setup (CA, server, client certs)

Your job:

1. **Enable TLS correctly**: set `tls-port` (e.g. 6379) and decide whether to keep the plaintext `port 0` (disable plaintext) or run both during migration. Redis needs TLS built in (standard since 6.0).
2. **Configure server certs**: `tls-cert-file`, `tls-key-file`, and `tls-ca-cert-file` (or `tls-ca-cert-dir`). Ensure the cert chain and SAN/CN match the hostname clients use.
3. **Client authentication**: `tls-auth-clients yes` (default) requires clients to present a valid cert (mTLS); set `no`/`optional` only deliberately. Explain the security tradeoff.
4. **Replication over TLS**: set `tls-replication yes` so replicas connect to the master over TLS; the replica also needs client cert config.
5. **Cluster bus over TLS**: `tls-cluster yes` encrypts the cluster bus; all nodes must agree.
6. **Protocol and ciphers**: restrict with `tls-protocols "TLSv1.2 TLSv1.3"` and set `tls-ciphers`/`tls-ciphersuites`; disable weak/legacy protocols.
7. **Client connection**: clients must use `rediss://` or `redis-cli --tls --cert --key --cacert`. Verify cert expiry and rotation plan.
8. **Validate the handshake**: test with redis-cli --tls and openssl s_client; check for hostname mismatch, expired certs, and untrusted CA.

Mark DESTRUCTIVE: setting `port 0` (disables plaintext, can lock out non-TLS clients), CONFIG changes that force mTLS before clients have certs, CONFIG REWRITE persisting a broken TLS config.

---

Version/topology: [DESCRIBE]
Current TLS config: [PASTE]
Certificate setup: [DESCRIBE]

Why this prompt works

TLS on Redis fails in blunt, total ways — one wrong directive (port 0, premature tls-auth-clients, an expired cert, a SAN mismatch) takes the whole service offline. This prompt walks server certs, mTLS, replication, and cluster-bus encryption in order, and flags exactly which changes can lock out clients so you stage the rollout safely.

How to use it

1. Describe topology — replication and Cluster need extra TLS flags.
2. Paste current TLS config and cert details (CA, SAN/CN, expiry).
3. State migration stage — are all clients TLS-capable yet?
4. Ask for a handshake validation checklist before disabling plaintext.

Useful commands

# Inspect TLS config
redis-cli CONFIG GET 'tls-*'
redis-cli CONFIG GET port          # 0 means plaintext disabled

# Connect over TLS with mutual auth
redis-cli --tls \
  --cert /etc/redis/certs/client.crt \
  --key  /etc/redis/certs/client.key \
  --cacert /etc/redis/certs/ca.crt \
  -h redis.internal -p 6379 PING

# Validate the handshake and cert chain from outside Redis
openssl s_client -connect redis.internal:6379 -CAfile /etc/redis/certs/ca.crt

# Check certificate expiry
openssl x509 -enddate -noout -in /etc/redis/certs/redis.crt

Example config

# redis.conf: TLS with mutual auth, encrypted replication and cluster bus
port 0                              # disable plaintext (only after clients migrated)
tls-port 6379

tls-cert-file /etc/redis/certs/redis.crt
tls-key-file  /etc/redis/certs/redis.key
tls-ca-cert-file /etc/redis/certs/ca.crt

tls-auth-clients yes               # require client certs (mTLS)
tls-replication yes                # encrypt master<->replica traffic
tls-cluster yes                    # encrypt the cluster bus

tls-protocols "TLSv1.2 TLSv1.3"    # pin modern protocols only
tls-ciphersuites "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"

Common findings this catches

• port 0 too early → plaintext clients locked out.
• Premature mTLS → all clients rejected for lacking certs.
• SAN/CN mismatch → handshake failures despite valid CA.
• Expired cert → total outage, no rotation plan.
• Missing tls-replication → replica traffic in cleartext.
• Legacy protocols/ciphers → weak encryption negotiated.
• Plaintext cluster bus → tls-cluster not set.

When to escalate

• Cert rotation causing outages — automate with the platform/PKI team.
• Cluster-wide TLS cutover — staged rollout with reliability review.
• Compliance-mandated encryption in transit — security sign-off and audit.