Update certificates¶

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

Certificates generated by the Operator are not renewed automatically. Starting with version 1.19.0, they are valid for 90 days, and the CA is valid for three years. To update them, you must provide new certificates to the Operator. Jump to the sections below for the steps.
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 certificates. Use the same steps to update external certificates. Read more about internal and external certificates in the About TLS section.

Before you start¶

Export the namespace where your cluster is deployed as an environment variable:

export NAMESPACE=<my-namespace>

Check your certificates for expiration¶

With cert-managerOperator-generated or manual TLS certificates

If you use cert-manager to generate certificates, do the following.

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

kubectl get certificate -n $NAMESPACE

Expected output

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 -n $NAMESPACE

Expected output

NAME                     READY   AGE
cluster1-pxc-ca-issuer   True    49m
cluster1-pxc-issuer      True    49m

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

{
  kubectl -n $NAMESPACE get secret/cluster1-ssl-internal -o jsonpath='{.data.tls\.crt'} | base64 --decode | openssl x509 -inform pem -noout -text | grep -E "Not Before|Not After"
  kubectl -n $NAMESPACE get secret/cluster1-ssl -o jsonpath='{.data.ca\.crt}' | base64 --decode | openssl x509 -inform pem -noout -text | grep -E "Not Before|Not After"
  }

Sample output

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

If the Operator created TLS certificates or you created them yourself, do the following.

List Secrets in your namespace and note the names used for external and internal TLS. By default these are cluster1-ssl and cluster1-ssl-internal. Otherwise the Secret names match the values of the sslSecretName and sslInternalSecretName options in your cluster Custom Resource.
```
kubectl get secrets -n $NAMESPACE
```
Optionally, confirm that both TLS Secrets exist and are of type kubernetes.io/tls:
```
kubectl get secrets -n $NAMESPACE -o custom-columns=NAME:.metadata.name,TYPE:.type | grep -E 'NAME|ssl'
```
Adjust the filter or Secret names to match your cluster.

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

{
  kubectl -n $NAMESPACE get secret/cluster1-ssl-internal -o jsonpath='{.data.tls\.crt}' | base64 --decode | openssl x509 -inform pem -noout -text | grep -E "Not Before|Not After"
  kubectl -n $NAMESPACE get secret/cluster1-ssl -o jsonpath='{.data.ca\.crt}' | base64 --decode | openssl x509 -inform pem -noout -text | grep -E "Not Before|Not After"
}

Sample output

Not Before=Nov  7 10:44:00 2025 GMT
Not After=Nov  7 10:44:00 2026 GMT
Not Before=Nov  7 10:54:00 2025 GMT
Not After=Nov  7 10:54:00 2026 GMT

Update valid certificates without downtime¶

This section explains how to update your certificates that are still valid, without downtime. For already expired certificates, refer to Update expired certificates section.

When to use this method:

Your certificates were generated by the Operator, but not using cert-manager
You generated the certificates manually or provided pre-existing certificates

To roll out new certificates (both CA and TLS) with the Operator, follow these steps.

Generate a new CA certificate (ca.pem), a new TLS certificate (server.pem) and a key for it (server-key.pem). Refer to the Generate certificates manually tutorial for the steps.
Create a Secret object and provide the new certificates within it. The Secret name must be in the format <existing-secret>-new.

The Operator automatically detects Secrets only if their names end with -new. Any Secret that does not have -new at the end of its name will be ignored and will not trigger a certificate update.

For example, if the existing Secret name is cluster1-ssl-internal, the new Secret name is cluster1-ssl-internal-new.

In the following command:

* `ca.pem` is added to the Secret as `ca.crt`
* `server.pem` is added to the Secret as `tls.crt`
* `server-key.pem` is added to the Secret as `tls.key`

```bash
kubectl -n $NAMESPACE create secret generic cluster1-ssl-internal-new \
--from-file=ca.crt=ca.pem \
--from-file=tls.crt=server.pem \
--from-file=tls.key=server-key.pem
```

On the next reconcile, the Operator detects the Secret and automatically updates the certificates. This triggers the rolling restart of the database Pods.

What happens under the hood

When the Operator reconciles the cluster and detects the Secret with the new TLS certificates, it does the following:

Combines a new and current CA certificates into a single file
Updates the current Secret to first append the combined CA certificate and then replace the TLS server and key certificates with new ones
Drops the old CA certificate leaving only the new one

On every step, the Operator performs the rolling restart of the database Pods to ensure the cluster availability and inter-node communication during the update.

Update expired certificates with downtime¶

This section explains how to update the certificates that have already expired. To check certificate validity, see Check your certificates for expiration.

If your certificates have been already expired, follow the pause - update Secrets - unpause procedure below:

Pause the cluster, 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 -n $NAMESPACE 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: November 3, 2026
Created: November 27, 2025