Event Streams uses 4 secrets to store the certificate authority (CA) certificates and keys for the cluster.
Secret Name | Description |
---|---|
\<instance-name\>-cluster-ca |
The secret containing the cluster CA private key. This is used to generate the certificates presented at the Event Streams endpoints, and for internal Kafka to Zookeeper connections. |
\<instance-name\>-cluster-ca-cert |
The secret containing the cluster CA certificate. This is used to generate the certificates presented at the Event Streams endpoints, and for internal Kafka to Zookeeper connections. |
\<instance-name\>-clients-ca |
The secret containing the private key used to sign the Mutual TLS KafkaUser certificates. These are used by clients connecting to Kafka over a Mutual TLS authenticated listener. |
\<instance-name\>-clients-ca-cert |
The secret containing the CA certificate used to sign the Mutual TLS KafkaUser certificates. These are used by clients connecting to Kafka over a Mutual TLS authenticated listener. |
Renewing auto-generated self-signed CA certificates for existing installations
By default, Event Streams uses self-signed CA certificates. These are automatically renewed when the default renewalDays
(default is 60 days) and validityDays
(default is 90 days) limits are met.
To set exactly when certificates are renewed, you can configure the renewalDays
and validityDays
values under the spec.strimziOverrides.clusterCa
and spec.strimziOverrides.clientsCa
properties. Validity periods are expressed as a number of days after certificate generation. For more information, see Certificate renewal and validity periods.
You can define maintenance windows
to ensure that the renewal of certificates are done at an appropriate time. For more information, see Maintenance time windows for rolling update.
You can also use the strimzi.io/force-renew
annotation to manually renew the certificates. This can be necessary if you need to renew the certificates for security reasons outside of the defined renewal periods and maintenance windows. For more information, see Manually renewing CA certificates.
Note: The configuration settings for renewal periods and maintenance windows, and the annotation for manual renewal only apply to auto-generated self-signed certificates. If you provided your own CA certificates and keys, you must manually renew these certificates as described in the following sections.
Renewing your own CA certificates for existing installations
If you provided your own CA certificates and keys, and need to renew only the CA certificate, complete the following steps. The steps provided demonstrate renewing the cluster CA certificate, but the steps are identical for renewing the clients CA certificate, with the exception of the secret name.
- Generate a new CA certificate by using the existing CA private key. The new certificate must have an identical CN name to the certificate it is replacing. Optionally, create a PKCS12 truststore with the new certificate if required.
- Replace the value of the
ca.crt
in the<instance-name>-cluster-ca-cert
secret with a base64-encoded string of the new certificate. Optionally, replace theca.p12
andca.password
values with the base64-encoded strings if required. -
Increment the
eventstreams.ibm.com/ca-cert-generation
annotation value in the<instance-name>-cluster-ca-cert
secret. If no annotation exists, add the annotation, and set the value to1
with the following command:kubectl annotate --namespace <namespace> secret <instance-name>-cluster-ca-cert eventstreams.ibm.com/ca-cert-generation=1
When the operator reconciles the next time, the pods roll to process the certificate renewal.
Renewing your own CA certificates and private keys for existing installations
If you provided your own CA Certificates and keys, and need to renew both the CA certificate and private key, complete the following steps. The steps provided demonstrate renewing the cluster CA certificate and key, but the steps are identical for renewing the clients CA certificate, with the exception of the secret name.
-
Pause the operator’s reconcile loop by running the following command:
kubectl annotate Kafka <instance-name> strimzi.io/pause-reconciliation="true" --overwrite=true
- Generate a new certificate and key pair. Optionally, create a PKCS12 truststore with the new certificate, if required.
- Replace the value of the
ca.key
in the<instance-name>-cluster-ca
secret with a base64-encoded string of the new key. -
Increment the
eventstreams.ibm.com/ca-key-generation
annotation value in the<instance-name>-cluster-ca
secret. If no annotation exists, add the annotation, setting the value to1
with the following command:kubectl annotate --namespace <namespace> secret <instance-name>-cluster-ca eventstreams.ibm.com/ca-key-generation=1
- Find the expiration date and time of the previous CA certificate by using OpenSSL or other certificate tooling.
-
Edit the
<instance-name>-cluster-ca-cert
secret. Rename theca.crt
element to beca-<expiry of ca.crt>.crt
.This will take the format of
ca-YYYY-MM-DDTHH-MM-SSZ.crt
(for example,ca-2022-05-24T10-20-30Z.crt
). Ensure the value of this element contains the base64-encoded string of the original CA certificate that you are renewing. - Add element
ca.crt
to the<instance-name>-cluster-ca-cert
secret with a base64-encoded string of the new certificate. Optionally, replace theca.p12
andca.password
values with the base64-encoded strings, if required. -
Increment the
eventstreams.ibm.com/ca-cert-generation
annotation value in the<instance-name>-cluster-ca-cert
secret. If no annotation exists, add the annotation, and set the value to1
with the following command:kubectl annotate --namespace <namespace> secret <instance-name>-cluster-ca-cert eventstreams.ibm.com/ca-cert-generation=1
-
Resume the operator’s reconcile loop by running the following command:
kubectl annotate Kafka <instance-name> strimzi.io/pause-reconciliation="false" --overwrite=true
When the operator reconciles the next time, the pods roll to process the certificate renewal. The pods might roll multiple times during the renewal process.
Updating clients after certificate change
If you renew the CA certificates, clients might need to update their truststore with the new certificate.
To update your client settings after a certificate change, see how to secure the connection.