Redis TLS is often seen as just a way to encrypt data in transit, but its real power lies in how it fundamentally changes the trust model for your Redis deployments.
Let’s fire up a Redis server and a client, both configured for TLS.
First, the server setup. We’ll need a certificate and a private key. For this example, we’ll generate self-signed ones, but in production, you’d use certificates from a trusted Certificate Authority (CA).
# Generate a private key
openssl genrsa -out redis.key 2048
# Generate a Certificate Signing Request (CSR)
openssl req -new -key redis.key -out redis.csr -subj "/CN=redis.local"
# Generate a self-signed certificate
openssl x509 -req -days 365 -in redis.csr -signkey redis.key -out redis.crt
Now, the Redis configuration file (redis.conf):
port 0 # Disable non-TLS port
tls-port 6379
tls-cert-file /path/to/your/redis.crt
tls-key-file /path/to/your/redis.key
tls-auth-clients no # For simplicity in this example; in production, use 'optional' or 'yes'
Start the Redis server:
redis-server /path/to/your/redis.conf
On the client side, we use redis-cli with TLS enabled. The client also needs to trust the server’s certificate. If you’re using self-signed certs like above, you’ll need to point redis-cli to the CA that signed it (which, in this self-signed case, is the redis.crt itself).
redis-cli --tls --cert /path/to/your/redis.crt --key /path/to/your/redis.key --cacert /path/to/your/redis.crt -p 6379
You’ll see the redis-cli prompt, and any commands you send will be encrypted.
The core problem Redis TLS solves isn’t just eavesdropping; it’s the implicit trust that non-TLS Redis deployments rely on. When Redis runs without TLS, any client that can reach the Redis port can connect and execute commands. Authentication (like requirepass) is a password check after the connection is established. TLS, however, establishes a secure, authenticated channel before any Redis commands are even sent. This means you can have clients that are only allowed to talk to Redis over TLS, and you can verify their identity.
Internally, when tls-port is enabled and port is disabled (or set to 0), Redis exclusively listens on the TLS port. When a client connects, Redis performs a TLS handshake. If tls-auth-clients is set to yes or optional, Redis will also verify the client’s certificate against the CA specified in tls-ca-cert-file (if provided). Only after a successful TLS handshake does Redis proceed to accept Redis commands. For replication, you’d configure replica-tls-auth and replica-tls-cert / replica-tls-key on the replica and tls-replication yes on the master. This ensures that the replication stream is also encrypted and authenticated.
The most surprising thing about Redis TLS is how granular you can get with client authentication. While tls-auth-clients no is common for initial setup or when network-level firewalls handle all access control, setting it to optional or yes allows Redis to act as a TLS endpoint that validates the identity of connecting clients using their certificates. This moves authentication from a simple password check to a cryptographic identity verification, enabling scenarios where specific applications or replicas are trusted based on their unique certificates, not just a shared secret. It’s a powerful way to enforce zero-trust principles within your Redis infrastructure.
Understanding how to manage certificate rotation for TLS-enabled Redis deployments is the next critical step.