In case your Valkey/Redis deployments use SSL/TLS, you’ll finally must rotate the TLS certificates. Maybe it’s as a result of the certificates are expiring, otherwise you made errors when creating them, or it might be that the personal key has been leaked. This text explains the method of rotating the TLS/SSL certificates utilized by Valkey/Redis deployments with out affecting service availability.
Setting and configurations
On this publish, we are going to rotate TLS certificates for a 6-node Valkey cluster (the method may also apply to standalone or Sentinel deployments)
Our working listing can have the next recordsdata: the server-new.pem and server-new-key.pem recordsdata would be the key pair used to switch server.pem and server-key.pem (You’ll be able to shortly create TLS key pairs by following our information 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 checks/ –tls/ – ca.pem – ca–key.pem – consumer.pem – consumer–consumer.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 recordsdata for every node can have the next parameters associated to TLS (along with different parameters required for clustering):
|
port 0 tls-port <your port quantity> tls-cert-file <absolute path to checks/tls/server.pem> tls-key-file <absolute path to checks/tls/server-key.pem> tls-ca-cert-file <absolute path to checks/tls/ca.pem> tls-auth-clients sure tls-replication sure tls-cluster sure |
Again up the TLS certificates presently getting used
Earlier than we do something, it’s very best to have a backup prepared. Within the occasion that something goes unsuitable, we are able to nonetheless revert to the earlier configurations.
|
mkdir checks/tls/backup cp checks/tls/server.pem checks/tls/backup/server.pem cp checks/tls/server–key.pem checks/tls/backup/server–key.pem |
Overwrite the presently used certificates with the brand new ones
We are going to exchange the content material of the outdated certificates with the brand new ones (server-new.pem and server-new-key.pem), and Valkey/Redis situations will decide it up after they reload the configuration
|
cp checks/tls/server–new.pem checks/tls/server.pem cp checks/tls/server–new–key.pem checks/tls/server–key.pem |
“Why can’t I simply replace the configs to level to the brand new key pair?”
In case you execute a CONFIG SET to level the tls-*-file configs to the brand new location, it won’t work. It’s because Valkey/Redis will reconfigure itself with each CONFIG SET command, and since you can’t replace a number of parameters directly, updating it sequentially will end in a key pair mismatch error:
|
v1:30001> CONFIG SET tls–cert–file /decide/weblog/checks/tls/server–new.pem (error) ERR CONFIG SET failed (presumably associated to argument ‘tls-cert-file’) – Unable to replace TLS configuration. Examine server logs. |
And the log file will present the next entries:
|
6088:M 03 Dec 2025 06:41:56.198 # Didn’t load personal key: /decide/weblog/checks/tls/server.key: error:05800074:x509 certificates routines::key values mismatch 6088:M 03 Dec 2025 06:41:56.198 # Failed making use of new configuration. Probably associated to new tls-cert-file setting. Restoring earlier settings. |
Reload the TLS configuration in Valkey situations
After overwriting the important thing pair contents, we are able to instruct Valkey situations to select up the brand new keys by executing CONFIG SET on a TLS-related parameter (we are able to set it to the present worth, no want to alter something right here):
|
v1:30001> config get tls–port 1# “tls-port” => “30001” v1:30001> config set tls–port 30001 OK |
Observe: Please bear in mind to run the CONFIG SET command on all nodes within the cluster
We will affirm that no lack of service occurred by grepping the situations’ log recordsdata for errors, or by querying the cluster’s standing:
|
v1:30001> cluster nodes eebc8ea9cb9277d72bc1293050536daf62a2390f 127.0.0.1:30006@40006 grasp – 0 1764745900000 6 related 13653–16383 a190b8d31b50d45472f3d1e45d0981504825c85d 127.0.0.1:30005@40005 grasp – 0 1764745902056 5 related 10923–13652 ae5ddd33578aee92e0586382fadfb34c63cd8ea9 127.0.0.1:30002@40002 grasp – 0 1764745901000 2 related 2731–5460 871621dcec7c0155ec65c0af90e643694c54cb74 127.0.0.1:30003@40003 grasp – 0 1764745901000 3 related 5461–8191 0af541d4f49be82be7a8267d4b6edbc9ab8f6543 127.0.0.1:30004@40004 grasp – 0 1764745901026 4 related 8192–10922 610929651b38a9503d3085ff484ce8121e831e39 127.0.0.1:30001@40001 myself,grasp – 0 0 1 related 0–2730 |
As we are able to see, after rotating, the situations can nonetheless talk with one another.
On the Shopper’s aspect
In case your Valkey/Redis situations have their new TLS certificates signed by the outdated Certificates Authority (CA), then your purchasers can nonetheless connect with the deployment usually. Nonetheless, when you would not have a CA (i.e., utilizing self-signed certificates) or use one other CA, be sure that your purchasers’ truststores have the related public keys imported to take care of service connectivity.
Conclusion
On this article, we’ve mentioned the process for rotating SSL/TLS certificates in a Valkey/Redis deployment with out incurring any downtime. Nonetheless, as at all times, please check the process earlier than making use of it to your manufacturing setting.
