Redis TLS setup, at its core, is about preventing passive eavesdropping and ensuring that data sent between your Redis client and server isn’t being read by an imposter.
Let’s see it in action. Imagine you have a Redis server and a client. Normally, they’d just talk over a plain TCP connection.
# On the Redis server (redis.conf)
port 6379
tls-port 6380
tls-cert-file /etc/redis/redis.crt
tls-key-file /etc/redis/redis.key
tls-ca-cert-file /etc/redis/ca.crt
With TLS enabled, the client initiates a handshake. It sends its supported cipher suites, the server picks one, they exchange certificates to verify each other’s identity, and then they establish a secure, encrypted channel. All subsequent SET or GET commands are encrypted and decrypted on the fly.
The problem this solves is fundamental: in any network, especially one you don’t fully control (like the internet or even a large internal network), anyone can potentially sniff your traffic. Without TLS, your Redis keys, values, and commands are all visible in plain text. This is a massive security hole if you’re storing sensitive data or if your commands could be used maliciously.
Internally, Redis uses OpenSSL for its TLS implementation. When you configure tls-port, you’re telling Redis to listen for TLS-encrypted connections on that port. The tls-cert-file and tls-key-file are your server’s identity – the certificate and its private key that clients will use to verify the server. The tls-ca-cert-file is the certificate of the Certificate Authority (CA) that signed your server’s certificate. Clients will use this to trust your server’s certificate.
To make a client connect via TLS, you’d use a command like this with redis-cli:
redis-cli --tls --tls-cert client.crt --tls-key client.key --tls-ca-cert ca.crt -p 6380
Here, --tls signals that the connection should be encrypted. --tls-cert and --tls-key provide the client’s own identity to the server (if mutual TLS is configured and required), and --tls-ca-cert tells the client which CA to trust for verifying the server’s certificate. The -p 6380 directs the client to the TLS-enabled port.
The exact levers you control are primarily around certificate management. You need to generate or obtain a server certificate and its private key, and a CA certificate that will be used by both server and clients to establish trust. You can use self-signed certificates for testing or internal environments, but for production, you’ll want certificates signed by a trusted public CA or your organization’s internal CA.
If you’re using Redis Sentinel or Redis Cluster, each node needs its TLS certificates configured, and the clients connecting to them (or the Sentinels/Cluster nodes themselves when communicating) will need to be configured for TLS.
When setting up TLS, the distinction between client authentication and server authentication is crucial. By default, Redis requires server authentication: the client verifies the server’s identity. If you also want the server to verify the client’s identity (mutual TLS or mTLS), you’ll need to configure tls-auth-clients yes on the server and provide client certificates and keys to the redis-cli or client library. This adds an extra layer of security, ensuring only authorized clients can connect.
The next concept you’ll likely encounter is optimizing TLS performance, as the handshake and encryption/decryption add overhead compared to plain TCP.