TLS certificates have an expiration date. If you are using TLS/SSL to encrypt data (either internally, externally, or both), you will need to update those certificates before they expire to ensure minimal disruption to normal operation.
One of the advantages of using cert-manager to create and manage your certificates is that it automatically updates the certificates before they expire. If you are not using cert-manager — that is, you are either creating your own secret to contain the keystore and truststore or defining them manually with helm properties — you will need to update the certificates yourself. Either way, shortly after the certificates are updated in Kubernetes, the operator takes responsibility for applying the new credentials to the cluster, the Operator, and the auxiliary services as appropriate.
To update the TLS keystores, truststores, and credentials when using a self-defined secret, you must:
Create a new version of the truststore and keystore using a certificate with a new expiration date.
Delete the current Kubernetes secret.
Create a new version of the same secret using the new files.
You create the new truststore and keystore using the same keytool commands used to create the original files, as described in Section 7.2, “Configuring TLS/SSL”. You then update the secret by deleting and recreating the secret using the kubectl create secret command from earlier, making sure you use the same name for the secret but the new SSL files. For example:
$ kubectl delete secret/my-ssl-creds $ kubectl create secret generic my-ssl-creds \ --from-file=keystore_data=newkey.jks \ --from-file=truststore_data=newtrust.jks \ --from-file=certificate=newcert.pem \ --from-literal=keystore_password=topsecret \ --from-literal=truststore_password=topsecret
If you defined the TLS/SSL credentials manually using Helm properties, you will need to reapply the new truststore and keystore files using a helm upgrade command and the --set-file flag.