If your Valkey/Redis deployments use SSL/TLS, you will eventually need to rotate the TLS certificates. Perhaps it is because the certificates are expiring, or you made mistakes when creating them, or it could be that the private key has been leaked. This article explains the process of rotating the TLS/SSL certificates used by Valkey/Redis deployments without affecting service availability.
Environment and configurations
In this post, we will rotate TLS certificates for a 6-node Valkey cluster (the process will also apply to standalone or Sentinel deployments)
Our working directory will have the following files: the server-new.pem and server-new-key.pem files will be the key pair used to replace server.pem and server-key.pem (You can quickly create TLS key pairs by following our guide on GitHub)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
ls -l tests/ -tls/ - ca.pem - ca-key.pem - client.pem - client-client.pem - server-new.pem - server-new-key.pem - server.pem - server-key.pem node1/ - valkey.conf node2/ - valkey.conf node3/ - valkey.conf node4/ - valkey.conf node5/ - valkey.conf node6/ - valkey.conf |
The configuration files for each node will have the following parameters related to TLS (in addition to other parameters required for clustering):
|
1 2 3 4 5 6 7 8 |
port 0 tls-port <your port number> tls-cert-file <absolute path to tests/tls/server.pem> tls-key-file <absolute path to tests/tls/server-key.pem> tls-ca-cert-file <absolute path to tests/tls/ca.pem> tls-auth-clients yes tls-replication yes tls-cluster yes |
Back up the TLS certificates currently being used
Before we do anything, it is ideal to have a backup ready. In the event that anything goes wrong, we can still revert to the previous configurations.
|
1 2 3 |
mkdir tests/tls/backup cp tests/tls/server.pem tests/tls/backup/server.pem cp tests/tls/server-key.pem tests/tls/backup/server-key.pem |
Overwrite the currently used certificates with the new ones
We will replace the content of the old certificates with the new ones (server-new.pem and server-new-key.pem), and Valkey/Redis instances will pick it up when they reload the configuration
|
1 2 |
cp tests/tls/server-new.pem tests/tls/server.pem cp tests/tls/server-new-key.pem tests/tls/server-key.pem |
“Why can’t I just update the configs to point to the new key pair?”
If you execute a CONFIG SET to point the tls-*-file configs to the new location, it will not work. This is because Valkey/Redis will reconfigure itself with every CONFIG SET command, and since you cannot update multiple parameters at once, updating it sequentially will result in a key pair mismatch error:
|
1 2 |
v1:30001> CONFIG SET tls-cert-file /opt/blog/tests/tls/server-new.pem (error) ERR CONFIG SET failed (possibly related to argument 'tls-cert-file') - Unable to update TLS configuration. Check server logs. |
And the log file will show the following entries:
|
1 2 |
6088:M 03 Dec 2025 06:41:56.198 # Failed to load private key: /opt/blog/tests/tls/server.key: error:05800074:x509 certificate routines::key values mismatch 6088:M 03 Dec 2025 06:41:56.198 # Failed applying new configuration. Possibly related to new tls-cert-file setting. Restoring previous settings. |
Reload the TLS configuration in Valkey instances
After overwriting the key pair contents, we can instruct Valkey instances to pick up the new keys by executing CONFIG SET on a TLS-related parameter (we can set it to the existing value, no need to change anything here):
|
1 2 3 4 |
v1:30001> config get tls-port 1# "tls-port" => "30001" v1:30001> config set tls-port 30001 OK |
Note: Please remember to run the CONFIG SET command on all nodes in the cluster
We can confirm that no loss of service occurred by grepping the instances’ log files for errors, or by querying the cluster’s status:
|
1 2 3 4 5 6 7 |
v1:30001> cluster nodes eebc8ea9cb9277d72bc1293050536daf62a2390f 127.0.0.1:30006@40006 master - 0 1764745900000 6 connected 13653-16383 a190b8d31b50d45472f3d1e45d0981504825c85d 127.0.0.1:30005@40005 master - 0 1764745902056 5 connected 10923-13652 ae5ddd33578aee92e0586382fadfb34c63cd8ea9 127.0.0.1:30002@40002 master - 0 1764745901000 2 connected 2731-5460 871621dcec7c0155ec65c0af90e643694c54cb74 127.0.0.1:30003@40003 master - 0 1764745901000 3 connected 5461-8191 0af541d4f49be82be7a8267d4b6edbc9ab8f6543 127.0.0.1:30004@40004 master - 0 1764745901026 4 connected 8192-10922 610929651b38a9503d3085ff484ce8121e831e39 127.0.0.1:30001@40001 myself,master - 0 0 1 connected 0-2730 |
As we can see, after rotating, the instances can still communicate with each other.
On the Client’s side
If your Valkey/Redis instances have their new TLS certificates signed by the old Certificate Authority (CA), then your clients can still connect to the deployment normally. However, if you do not have a CA (i.e., using self-signed certificates) or use another CA, ensure that your clients’ truststores have the relevant public keys imported to maintain service connectivity.
Conclusion
In this article, we have discussed the procedure for rotating SSL/TLS certificates in a Valkey/Redis deployment without incurring any downtime. However, as always, please test the procedure before applying it to your production environment.
Redis vs Valkey: Choosing the Right Fit for Your Organization
