Redis Password & TLS Security

You've connected Redis to your app, cached database queries, and maybe even used Pub/Sub for real-time features. But is your Redis instance locked down? Without a password and TLS encryption, your Redis data—session tokens, leaderboards, cached credentials—could be exposed to any attacker who can reach the port. This lesson shows you how to secure Redis with a password and TLS, moving from a development default to a production-grade fortress.

The problem this lesson solves

Redis runs on an open TCP port (6379 by default) with zero authentication. In development, that’s convenient. In production, it’s a ticking time bomb. A single redis-cli from any machine on the same network can flush all your caches, read session keys, or worse. The two core protections every Redis admin must add are:

• Password authentication (requirepass) — forces every client to prove identity with a shared secret.
• TLS encryption — prevents eavesdropping, man-in-the-middle attacks, and plaintext sniffing on the wire.

Pro tip: Even if you run Redis inside a VPC or behind a firewall, never skip TLS. Internal networks can be compromised too — defense in depth isn’t optional.

Core concept / mental model

Think of Redis security like a safe in an office building:

1. Password (requirepass) = the keypad code on the safe. Anyone who knows the code can open it.
2. TLS = steel walls that prevent anyone from seeing what code you type. Without TLS, an eavesdropper on the network can read the password in plaintext as you type it.

Together, they solve two separate problems: - Authentication (prove who you are) - Encryption (keep transmitted data secret)

Redis calls the password requirepass in the config file. TLS is enabled via the tls-port directive alongside a certificate file and key.

How it works step by step

Step 1: Enable password authentication

Edit your redis.conf (or pass via command line):

requirepass MySup3rS3cr3tP@ss

When any client connects, Redis now returns NOAUTH Authentication required until the client issues AUTH <password>.

Step 2: Enable TLS

For TLS, you need a certificate (.crt), a private key (.key), and optionally a CA certificate to verify peers. Redis supports both one-way (server-only) and mutual (mTLS) authentication.

In redis.conf:

port 0                              # disable plain TCP
# or keep both: port 6379 and tls-port 6380
tls-port 6380
tls-cert-file /etc/redis/redis.crt
tls-key-file /etc/redis/redis.key
# Optionally:
tls-ca-cert-file /etc/redis/ca.crt
tls-auth-clients yes               # enable mTLS

Important: Set port 0 to entirely disable non-TLS connections, or keep port for backwards compatibility during migration.

Step 3: Restart and verify

redis-server /path/to/redis.conf

Test password auth without TLS (will fail if port 0):

redis-cli -a MySup3rS3cr3tP@ss PING

Test with TLS:

redis-cli --tls --cert /etc/redis/client.crt --key /etc/redis/client.key --cacert /etc/redis/ca.crt -p 6380 -a MySup3rS3cr3tP@ss PING

Hands-on walkthrough

Let's build a minimal secure Redis setup on a local machine. You'll need: - Redis 6+ installed (with TLS support compiled — check redis-server --version includes tls) - OpenSSL for generating self-signed certificates for testing

Example 1: Generate self-signed certs (for testing only)

# Create a Certificate Authority (CA)
openssl req -x509 -newkey rsa:4096 -keyout ca.key -out ca.crt -days 365 -nodes -subj "/CN=RedisCA"

# Create server cert signed by that CA
openssl req -newkey rsa:4096 -keyout redis.key -out redis.csr -nodes -subj "/CN=localhost"
openssl x509 -req -in redis.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out redis.crt -days 365

Example 2: Minimal secure config

Save as secure-redis.conf:

port 0
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
tls-auth-clients no                # one-way TLS for simplicity
tls-replication yes                # also encrypt replication traffic
requirepass MySup3rS3cr3tP@ss

Example 3: Connect from Python with password + TLS

import redis

# Connect with password and TLS
client = redis.Redis(
    host='localhost',
    port=6380,
    password='MySup3rS3cr3tP@ss',
    ssl=True,
    ssl_certfile='/etc/redis/client.crt',    # if mTLS enabled
    ssl_keyfile='/etc/redis/client.key',
    ssl_ca_certs='/etc/redis/ca.crt'
)

client.set('secure_key', 'value_encrypted')
print(client.get('secure_key'))  # b'value_encrypted'

Expected output:

b'value_encrypted'

If TLS is not needed (but password only):

client = redis.Redis(host='localhost', port=6379, password='MySup3rS3cr3tP@ss')

Compare options / when to choose what

Rule of thumb: If Redis is reachable from the public internet or crosses network boundaries (e.g., cloud to on-prem), always use password + TLS (one-way at minimum).

Troubleshooting & edge cases

"NOAUTH Authentication required"

You forgot to send the password. Every new connection must call AUTH <password> — clients like redis-py do this automatically if you pass password=. But raw redis-cli commands without -a will fail.

Fix: Always provide -a or AUTH after connect.

TLS handshake fails: "certificate verify failed"

Common cause: The server’s certificate was signed by a CA not trusted by the client. In testing with self-signed certs, you must pass --cacert ca.crt.

Fix: Ensure tls-ca-cert-file points to the correct CA, and the client knows it.

Client cannot connect after enabling TLS

Symptoms: Connection refused or timeout. Check that Redis is listening on the TLS port — netstat -tlnp | grep 6380. Also, if you set port 0, the default redis-cli (no --tls) cannot connect.

Fix: Use redis-cli -p 6380 --tls ... or re-enable a plain port for migration.

Password visible in redis-cli command history

Using -a on the command line exposes the password in shell history (~/.bash_history).

Fix: Set REDISCLI_AUTH environment variable instead: export REDISCLI_AUTH='MySup3rS3cr3tP@ss'.

What you learned & what's next

You can now explain why unsecured Redis is dangerous, configure requirepass, enable TLS (with one-way or mutual auth), and connect securely from any client. You practiced generating test certificates, wrote a minimal secure config, and tested connections from both redis-cli and Python.

Next lesson: Redis Security Best Practices — covering ACLs, renaming dangerous commands, and network-level isolation with iptables or cloud security groups.