// Module included in the following assemblies:
//
// assembly-security.adoc

[id='certificate-authorities-{context}']
= Certificate Authorities

To support encryption, each {ProductName} component needs its own private keys and public key certificates.
All component certificates are signed by an internal Certificate Authority (CA) called the _cluster CA_.

Similarly, each Kafka client application connecting to {ProductName} using TLS client authentication needs to provide private keys and certificates.
A second internal CA, named the _clients CA_, is used to sign certificates for the Kafka clients.

== CA certificates

Both the cluster CA and clients CA have a self-signed public key certificate.

Kafka brokers are configured to trust certificates signed by either the cluster CA or clients CA.
Components that clients do not need to connect to, such as ZooKeeper, only trust certificates signed by the cluster CA.
Unless TLS encryption for external listeners is disabled, client applications must trust certificates signed by the cluster CA.
This is also true for client applications that perform xref:con-mutual-tls-authentication-deployment-configuration-kafka[mutual TLS authentication]. 

By default, {ProductName} automatically generates and renews CA certificates issued by the cluster CA or clients CA.
You can configure the management of these CA certificates in the `Kafka.spec.clusterCa` and `Kafka.spec.clientsCa` objects.
Certificates provided by users are not renewed.

You can provide your own CA certificates for the cluster CA or clients CA.
For more information, see xref:installing-your-own-ca-certificates-{context}[].
If you provide your own certificates, you must manually renew them when needed.

== Validity periods of CA certificates

CA certificate validity periods are expressed as a number of days after certificate generation.
You can configure the validity period of:

* Cluster CA certificates in `Kafka.spec.clusterCa.validityDays`
* Client CA certificates in `Kafka.spec.clientsCa.validityDays`
