Update certificates¶

How your TLS certificates are updated depends on how they were created:

Certificates generated by the Operator are long-term. If you need to rotate them, you must do it manually.
Certificates issued by the cert-manager are short-term. They are valid for 3 months. The cert-manager automatically reissues the certificates on schedule and without downtime.

Certificates manually generated by you are not renewed automatically. It is your responsibility to timely update them. Use the steps in the following sections for how to do it.

Check your certificates for expiration¶

Check the necessary secrets names (ps-cluster1-ssl and ps-cluster1-ca-cert by default):

kubectl get certificate -n $NAMESPACE

Sample output

ps-cluster1-ca-cert   True    ps-cluster1-ca-cert   45m
ps-cluster1-ssl       True    ps-cluster1-ssl       43m

Optionally you can also check that the certificates issuer is up and running:
```
kubectl get issuer -n $NAMESPACE
```
The response should be as follows:
```
NAME                              READY   AGE
ps-cluster1-ps-ca-issuer   True    40m
ps-cluster1-ps-issuer      True    38m
```
Note

If you don’t use cert-manager, list your secrets:
```
kubectl get secrets -n $NAMESPACE
```
Then either use the default ones or the one you created

Use the following command to find out the certificates validity dates, substituting Secrets names if necessary:

{
kubectl get secret/ps-cluster1-ca-cert -n ps -o jsonpath='{.data.tls\.crt}' | base64 --decode | openssl x509 -noout -dates
kubectl get secret/ps-cluster1-ssl -o jsonpath='{.data.ca\.crt}' | base64 --decode | openssl x509 -noout -dates
}

Sample output

notBefore=Nov  7 10:54:00 2025 GMT
notAfter=Nov  7 10:54:00 2026 GMT

Update certificates without downtime¶

If you don’t use cert-manager and have created certificates manually, you can follow the next steps to perform a no-downtime update of these certificates if they are still valid.

Note

For already expired certificates, follow the alternative way.

Having non-expired certificates, you can roll out new certificates (both CA and TLS) with the Operator as follows:

Generate a new CA certificate (ca.pem), a new TLS certificate (server.pem) and a key for it (server-key.pem).

Get the current CA (ca.pem.old) and TLS (tls.pem.old) certificates and the TLS certificate key (tls.key.old):

kubectl get secret/ps-cluster1-ssl -o jsonpath='{.data.ca\.crt}' | base64 --decode > ca.pem.old
kubectl get secret/ps-cluster1-ssl -o jsonpath='{.data.tls\.crt}' | base64 --decode > tls.pem.old
kubectl get secret/ps-cluster1-ssl -o jsonpath='{.data.tls\.key}' | base64 --decode > tls.key.old

Combine new and current ca.pem into a ca.pem.combined file:
```
cat ca.pem ca.pem.old >> ca.pem.combined
```

Create a new Secrets object with the old TLS certificate (tls.pem.old) and key (tls.key.old), but a new combined ca.pem (ca.pem.combined):

kubectl create secret generic ps-cluster1-ssl \
--from-file=tls.crt=server.pem.old \
--from-file=tls.key=server-key.pem.old \
--from-file=ca.crt=ca.pem.combined \
--type=kubernetes.io/tls -o yaml --dry-run=client | kubectl apply -f -

The cluster will go through a rolling restart. This process will not cause issues, because every node has the old TLS certificate/key, and both new and old CA certificates.

Create a new Secrets object again. This time use a new TLS certificate (server.pem in the example) and a new TLS key (server-key.pem), and again the combined CA certificate (ca.pem.combined):

kubectl create secret generic ps-cluster1-ssl \
--from-file=tls.crt=server.pem \
--from-file=tls.key=server-key.pem \
--from-file=ca.crt=ca.pem.combined \
--type=kubernetes.io/tls -o yaml --dry-run=client | kubectl apply -f -

The cluster will go through a rolling restart. This process will not cause issues, because every node already has a new CA certificate (as a part of the combined CA certificate), and can successfully allow joiners with new TLS certificate to join. A joiner node also has a combined CA certificate, so it can authenticate against older TLS certificate.

Create a final Secrets object: use the new TLS certificate (server.pmm) and its key (server-key.pem), and only the new CA certificate (ca.pem):

kubectl create secret generic ps-cluster1-ssl \
--from-file=tls.crt=server.pem \
--from-file=tls.key=server-key.pem \
--from-file=ca.crt=ca.pem \
--type=kubernetes.io/tls -o yaml --dry-run=client | kubectl apply -f -

The cluster will go through a rolling restart, but it will do it without problems: the old CA certificate is removed, and every node is already using new TLS certificate and no nodes rely on the old CA certificate any more.

Last update: 2025-11-12