TLS for Client and Internode Traffic, Certificate Lifecycle, and Performance Considerations

Learning outcomes

This lesson turns TLS for Client and Internode Traffic, Certificate Lifecycle, and Performance Considerations into an observable AtlasMart workflow with explicit correctness, failure, and production boundaries.

1. Problem: correct ACLs over plaintext still leak

AtlasMart has now restricted commands and keys, but the Chapter 22 ACL-mechanics node deliberately uses plaintext TCP on loopback. On any untrusted network, AUTH credentials and application data can be exposed or modified in transit. TLS provides transport confidentiality, integrity, and certificate-based peer verification; it is independent of Redis ACL authorization.

2. TLS vocabulary before configuration

A Certificate Authority (CA) signs certificates. A server certificate binds a public key to allowed identities such as DNS names in Subject Alternative Name (SAN). The private key must remain secret. Mutual TLS (mTLS) additionally asks the client to present a certificate trusted by the server. Redis still performs ACL authentication/authorization after the TLS channel exists; a valid client certificate does not automatically grant Redis commands.

3. Generate short-lived disposable certificates

Run this in a shell with OpenSSL (Linux/macOS, WSL, or Git Bash/OpenSSL on Windows). The lab CA and keys live only under ch22-certs/; do not commit them. The seven-day lifetime is intentionally short to force lifecycle thinking. One lab server certificate contains both node DNS names and loopback IP; production should normally issue per-node certificates and protect private keys with your platform secret mechanism.

#!/usr/bin/env bashset -euo pipefailmkdir -p ch22-certscd ch22-certsrm -f ca.key ca.crt server.key server.csr server.crt client.key client.csr client.crt server.ext client.ext ca.srlopenssl genrsa -out ca.key 2048openssl req -x509 -new -sha256 -days 7 -key ca.key -out ca.crt -subj "/CN=AtlasMart Chapter22 Lab CA"openssl genrsa -out server.key 2048openssl req -new -sha256 -key server.key -out server.csr -subj "/CN=atlasmart-redis-ch22-primary"cat > server.ext <<'EOF'subjectAltName=DNS:atlasmart-redis-ch22-primary,DNS:atlasmart-redis-ch22-replica,IP:127.0.0.1extendedKeyUsage=serverAuth,clientAuthEOFopenssl x509 -req -sha256 -days 7 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -extfile server.extopenssl genrsa -out client.key 2048openssl req -new -sha256 -key client.key -out client.csr -subj "/CN=atlasmart-ch22-client"printf 'extendedKeyUsage=clientAuth' > client.extopenssl x509 -req -sha256 -days 7 -in client.csr -CA ca.crt -CAkey ca.key -CAserial ca.srl -out client.crt -extfile client.extchmod 600 ca.key server.key client.key 2>/dev/null || trueopenssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltNameopenssl x509 -in client.crt -noout -subject -issuer -dates

4. Configure a TLS-only primary

Redis can listen on a TLS port while disabling its plaintext port with port 0. By default, tls-auth-clients yes means clients must also provide a certificate signed by the trusted CA. The Redis ACL user/password remains required; mTLS and ACLs are independent controls.

bind 0.0.0.0protected-mode yesport 0tls-port 6379tls-cert-file /run/secrets/server_crttls-key-file /run/secrets/server_keytls-ca-cert-file /run/secrets/ca_crttls-auth-clients yesaclfile /data/users.acldir /dataappendonly yesappendfsync everysecsave 300 10maxmemory 0maxmemory-policy noevictionenable-protected-configs noenable-debug-command noenable-module-command no

5. Configure TLS replication with a dedicated ACL identity

The replica also listens only on TLS and sets tls-replication yes for its outgoing primary connection. It authenticates as replica-sync, whose ACL rules permit only PSYNC/REPLCONF/PING. The clear masterauth in this disposable file is intentionally treated as a secret later; production configuration delivery must protect it.

bind 0.0.0.0protected-mode yesport 0tls-port 6379tls-cert-file /run/secrets/server_crttls-key-file /run/secrets/server_keytls-ca-cert-file /run/secrets/ca_crttls-auth-clients yestls-replication yesaclfile /data/users.aclreplicaof atlasmart-redis-ch22-primary 6379masteruser replica-syncmasterauth AtlasMart-Ch22-Repl-Lab-Only-2026dir /dataappendonly yesappendfsync everysecsave 300 10maxmemory 0maxmemory-policy noevictionenable-protected-configs noenable-debug-command noenable-module-command no

6. Compose the isolated two-node TLS lab

Only the primary is published to the host, and only on loopback. Both nodes share the CA/certificate directory read-only. A one-shot seed service copies the hash-only bootstrap ACL file into each node’s named data volume on first start, applies restrictive ownership, and exits. Redis itself still starts through the official image’s normal redis-server entrypoint. TLS certificates/private keys are supplied as Compose secrets rather than ordinary writable files. ACL SAVE later updates each node’s own /data/users.acl.

name: atlasmart-redis-ch22services:  seed-acl:    image: redis:8.10.1    container_name: atlasmart-redis-ch22-seed-acl    restart: "no"    user: "0:0"    command: ["sh","-c","set -eu; for d in /primary /replica; do if [ ! -f $$d/users.acl ]; then cp /run/secrets/users_acl $$d/users.acl; chown redis:redis $$d/users.acl; chmod 600 $$d/users.acl; fi; done"]    secrets: [users_acl]    volumes:      - ch22-primary-data:/primary      - ch22-replica-data:/replica  primary:    image: redis:8.10.1    container_name: atlasmart-redis-ch22-primary    hostname: atlasmart-redis-ch22-primary    restart: "no"    depends_on:      seed-acl:        condition: service_completed_successfully    ports:      - "127.0.0.1:6422:6379"    command: ["redis-server","/usr/local/etc/redis/redis.conf"]    secrets: [ca_crt, server_crt, server_key]    volumes:      - ./primary.conf:/usr/local/etc/redis/redis.conf:ro      - ch22-primary-data:/data    networks: [security]  replica:    image: redis:8.10.1    container_name: atlasmart-redis-ch22-replica    hostname: atlasmart-redis-ch22-replica    restart: "no"    depends_on:      seed-acl:        condition: service_completed_successfully    command: ["redis-server","/usr/local/etc/redis/redis.conf"]    secrets: [ca_crt, server_crt, server_key]    volumes:      - ./replica.conf:/usr/local/etc/redis/redis.conf:ro      - ch22-replica-data:/data    networks: [security]  client:    image: redis:8.10.1    profiles: ["tools"]    entrypoint: ["redis-cli"]    secrets: [ca_crt, client_crt, client_key]    networks: [security]networks:  security:    name: atlasmart-redis-ch22-netvolumes:  ch22-primary-data:  ch22-replica-data:secrets:  users_acl:    file: ./users.acl  ca_crt:    file: ./ch22-certs/ca.crt  server_crt:    file: ./ch22-certs/server.crt  server_key:    file: ./ch22-certs/server.key  client_crt:    file: ./ch22-certs/client.crt  client_key:    file: ./ch22-certs/client.key

docker compose -f ch22-compose.yaml up -ddocker compose -f ch22-compose.yaml psdocker port atlasmart-redis-ch22-primary 6379docker network inspect atlasmart-redis-ch22-net

#!/usr/bin/env bashset -euo pipefail: "${REDISCLI_AUTH:?Set REDISCLI_AUTH to the disposable Chapter 22 password}"CH22_HOST="${CH22_HOST:-atlasmart-redis-ch22-primary}"CH22_USER="${CH22_USER:-academy-admin}"exec docker compose -f ch22-compose.yaml run --rm   -e REDISCLI_AUTH client   -h "$CH22_HOST" -p 6379 --tls   --cacert /run/secrets/ca_crt   --cert /run/secrets/client_crt --key /run/secrets/client_key   --user "$CH22_USER" "$@"

7. Prove the TLS handshake independently of Redis AUTH

Use OpenSSL to verify the server chain and loopback SAN while presenting the lab client certificate. A successful handshake with Verify return code: 0 (ok) proves the certificate path/peer verification. It does not prove the client has any Redis ACL permissions.

openssl s_client -connect 127.0.0.1:6422 \  -verify_ip 127.0.0.1 -verify_return_error \  -CAfile ch22-certs/ca.crt \  -cert ch22-certs/client.crt -key ch22-certs/client.key < /dev/null

8. Prove Redis identity over mTLS

A transient pinned Redis container acts as the client on the private lab network, so the mandatory path does not require host redis-cli. It presents the client certificate, verifies the CA, then authenticates as atlasmart-app. PING should succeed. Run a second command as admin to inspect ACL WHOAMI and CLIENT LIST.

REDISCLI_AUTH=AtlasMart-Ch22-App-Lab-Only-2026 CH22_USER=atlasmart-app ./ch22-cli.sh PING

docker run --rm --network atlasmart-redis-ch22-net \  -e REDISCLI_AUTH=AtlasMart-Ch22-Admin-Lab-Only-2026 \  -v "$PWD/ch22-certs:/certs:ro" redis:8.10.1 \  redis-cli -h atlasmart-redis-ch22-primary -p 6379 --tls --cacert /certs/ca.crt --cert /certs/client.crt --key /certs/client.key --user academy-admin ACL WHOAMIdocker exec -e REDISCLI_AUTH=AtlasMart-Ch22-Admin-Lab-Only-2026 atlasmart-redis-ch22-primary redis-cli --tls --cacert /certs/ca.crt --cert /certs/client.crt --key /certs/client.key --user academy-admin -p 6379 INFO replication

9. What replication evidence proves—and what it does not

On the primary, expect one connected replica; on the replica, expect master_link_status:up. Because the primary has no plaintext port and requires trusted client certificates, a live replication link demonstrates that the replica’s TLS/auth configuration is interoperable. It does not prove zero replication lag, zero data loss, certificate revocation, or production-grade key custody.

10. Internode settings for Cluster and Sentinel

For Redis Cluster, tls-cluster yes enables TLS for the Cluster bus/cross-node connections. Sentinel uses common Redis TLS configuration, and tls-replication yes determines TLS for Sentinel-to-data-node and Sentinel-to-Sentinel paths. Do not enable only client TLS and assume those other planes became encrypted automatically.

11. Measure TLS cost instead of inventing a percentage

TLS adds encryption/decryption and integrity-check overhead; Redis 8 supports I/O threading with TLS. Do not freeze a universal throughput penalty. Benchmark the same payload, connection count, pipeline depth, CPU limits, persistence mode, and topology on an identical disposable plaintext control versus TLS, record p50/p95/p99 and throughput, then choose capacity headroom from your environment.

docker run --rm --network atlasmart-redis-ch22-net \  -v "$PWD/ch22-certs:/certs:ro" redis:8.10.1 \  redis-benchmark -h atlasmart-redis-ch22-primary -p 6379 --tls \  --cacert /certs/ca.crt --cert /certs/client.crt --key /certs/client.key \  --user atlasmart-app -a AtlasMart-Ch22-App-Lab-Only-2026 \  -t get -n 10000 -c 20 -P 4 -d 512

12. Deliberately wrong: disable certificate verification to “fix TLS”

Using an untrusted certificate, disabling verification, or accepting any hostname restores encryption without trustworthy peer identity and can enable man-in-the-middle attacks. Repair the certificate chain/SAN/trust store; never turn verification off as the production fix. Also avoid committing the lab CA private key, server key, client key, or clear client secrets.

13. Certificate lifecycle and rollback

Track issuer, SANs, not-before/not-after, deployment owners, and which Redis planes consume each certificate. Rotate by introducing trust for the new CA/cert first, verifying new connections, then removing old trust only after all clients/replicas/Sentinels/Cluster nodes have moved. Keep a rollback window appropriate to your risk model. Lesson 5 repeats the same staged idea for ACL passwords.

Summary and next step

TLS for Client and Internode Traffic, Certificate Lifecycle, and Performance Considerations is now connected to observable Redis behavior, bounded failure cases, and production tradeoffs. Keep the evidence and cleanup state from this lesson; next, continue with Disable/Restrict Dangerous Administration, Protect CONFIG/MODULE-Like Capabilities, and Network Access.

Authoritative references

• Redis security
• Redis ACL tutorial
• ACL SETUSER
• ACL GETUSER
• ACL LIST
• ACL WHOAMI
• ACL CAT
• ACL DRYRUN
• ACL LOG
• ACL SAVE
• ACL LOAD
• AUTH
• Redis TLS
• CLIENT LIST
• CLIENT KILL
• CONFIG GET
• CONFIG SET
• MODULE LOAD
• Redis replication — ACL authentication
• Redis Sentinel — ACL authentication
• Redis Cluster specification
• Redis 8.10 release notes
• Redis 8.10 — what is new
• Redis licenses
• Docker Official Image — Redis