Rolling Back Cluster Certificates in Redis Software

Redis Software clusters are deployed with a default self-signed certificate. Many organizations replace this certificate with one issued by an internal or public Certificate Authority (CA). If you later decide to revert to a self-signed certificate, there's no built-in rollback option. Instead, you must generate a new self-signed certificate and upload it to the cluster.

This guide explains why rollback is not supported, how to generate a new self-signed certificate, how to install it safely, and how to validate the cluster after replacement.

Key Behavior to Understand

Redis Software does not retain previously installed certificates.

Once a certificate is replaced:

• The original self-signed certificate is not stored.

• There's no “restore previous certificate” option.

• The supported method is to generate and upload a new certificate.

Reinstalling the cluster would regenerate default certificates, but this is disruptive and typically unnecessary.

Before You Begin

Ensure you have:

• Cluster Manager administrative access

• A maintenance window (recommended, as TLS updates may briefly impact connectivity)

• A backup copy of the currently installed certificate and key (recommended)

• Access to update client trust stores if required

Step 1: Generate a New Self-Signed Certificate

Redis Software 6.2.18-70 and Later

Redis Software 6.2.18-70 and later includes a built-in script to generate properly formatted self-signed certificates.

Follow the official certificate generation documentation:https://redis.io/docs/latest/operate/rs/security/certificates/create-certificates/

This method ensures:

• Proper Subject Alternative Name (SAN) configuration

• Correct key usage extensions

• Compatibility with inter-node TLS

• Compliance with Redis Software certificate requirements

Earlier Versions

If running an earlier version:

• Use OpenSSL to generate a self-signed certificate

• Ensure the certificate includes:

  • All cluster node hostnames in the SAN field

  • Appropriate key usage extensions

  • A 2048-bit or stronger key

Follow the same official certificate structure guidelines linked above.

Step 2: Upload the Certificate to the Cluster

1. Log in to the Cluster Manager UI

2. Navigate to:
   Cluster → Security → Certificates

3. Upload:

   • Server certificate (PEM format)

   • Private key

   • CA certificate (if applicable)

4. Apply the changes

The cluster will reload TLS configuration. In some environments, this may briefly interrupt client connections.

Step 3: Validate Cluster Health

After installation:

• Confirm cluster status is healthy

• Verify all nodes are reachable

• Test client TLS connectivity

• Confirm inter-node communication remains operational

Example client test:

redis-cli --tls -h <host> -p <port>

If mutual TLS is enabled, ensure client certificates are still trusted.

Troubleshooting

Clients Cannot Connect After Certificate Replacement

Common causes:

• Client does not trust the new CA

• SAN does not match the hostname used by the client

• Certificate and private key do not match

Resolution:

• Update client trust store

• Regenerate certificate with correct SAN entries

• Validate key and certificate pair integrity

Cluster Nodes Report TLS Errors

Common causes:

• Missing node DNS names in SAN

• Incorrect certificate extensions

Resolution:

• Regenerate the certificate using the documented Redis Software process

• Ensure all node hostnames are included

When Is Cluster Reinstallation Required?

Reinstallation regenerates default self-signed certificates but removes cluster configuration. This approach should only be considered in full-rebuild scenarios. Generating and uploading a new certificate is the supported and recommended method.