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.

This document describes how to update the internal certificate.

Check your certificates for expiration¶

Check the necessary secrets names (cluster1-ssl and cluster1-ssl-internal by default):

kubectl get certificate

You will have the following response:

NAME                    READY   SECRET                  AGE
cluster1-ca-cert        True    cluster1-ca-cert        49m
cluster1-ssl            True    cluster1-ssl            49m
cluster1-ssl-internal   True    cluster1-ssl-internal   49m

Optionally you can also check that the certificates issuer is up and running:
```
kubectl get issuer
```
The response should be as follows:
```
NAME                     READY   AGE
cluster1-pxc-ca-issuer   True    49m
cluster1-pxc-issuer      True    49m
```
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/cluster1-ssl-internal -o jsonpath='{.data.tls\.crt}' | base64 --decode | openssl x509 -inform pem -noout -text | grep "Not After"
  kubectl get secret/cluster1-ssl -o jsonpath='{.data.ca\.crt}' | base64 --decode | openssl x509 -inform pem -noout -text | grep "Not After"
  }

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/cluster1-ssl -o jsonpath='{.data.ca\.crt}' | base64 --decode > ca.pem.old
kubectl get secret/cluster1-ssl -o jsonpath='{.data.tls\.crt}' | base64 --decode > tls.pem.old
kubectl get secret/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 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 cluster1-ssl \
--from-file=tls.crt=server.pem \
--from-file=tls.key=server-key.pem \
--from-file=ca.crt=ca.pem.combined \
--type=Opague -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 cluster1-ssl \
--from-file=tls.crt=server.pem \
--from-file=tls.key=server-key.pem \
--from-file=ca.crt=ca.pem \
--type=Opague -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.

Update certificates with downtime¶

If your certificates have been already expired (or if you continue to use the Operator version prior to 1.9.0), you should move through the pause - update Secrets - unpause route as follows.

Pause the cluster in a standard way, and make sure it has reached its paused state.

If cert-manager is used, delete issuer and TLS certificates:

$ {
  kubectl delete issuer/cluster1-pxc-ca
  kubectl delete certificate/cluster1-ssl certificate/cluster1-ssl-internal
  }

Delete Secrets to force the SSL reconciliation:

kubectl delete secret/cluster1-ssl secret/cluster1-ssl-internal

Check certificates to make sure reconciliation have succeeded.
Unpause the cluster in a standard way, and make sure it has reached its running state.

Keep certificates after deleting the cluster¶

In case of cluster deletion, objects, created for SSL (Secret, certificate, and issuer) are not deleted by default.

If the user wants the cleanup of objects created for SSL, there is a finalizers.delete-ssl option in deploy/cr.yaml: if this finalizer is set, the Operator will delete Secret, certificate and issuer after the cluster deletion event.

Last update: December 4, 2025
Created: December 4, 2025