# Configure mutual TLS (mTLS) authentication on Confluent Cloud Configure mutual TLS (mTLS) authentication by uploading your Certificate Authority (CA) certificate to Confluent Cloud, allowing clients to authenticate using X.509 certificates signed by your CA. Confluent Cloud brokers validate client certificates against your CA while presenting Let’s Encrypt server certificates for their identity. Use mTLS authentication when you have a Public Key Infrastructure (PKI) with an internal CA, compliance requires certificate-based authentication, you want hardware security module (HSM) support for private keys, or when you need certificate revocation using certificate revocation lists (CRLs). ## Requirements The following sections list the requirements for mTLS configuration. ### Supported cluster types The following cluster types support mTLS, with support for CRLs: - Dedicated clusters for all cloud providers - AWS Enterprise clusters - AWS Freight clusters ### Region availability - Dedicated clusters that support mTLS are available at AWS, Azure, and Google Cloud. - Enterprise clusters that support mTLS are available in all AWS regions. - Freight clusters that support mTLS are available in all AWS regions. For the full list of regions where mTLS is supported, by cluster type, see [Confluent Cloud Regions and Availability by Cloud Provider](../../../../../get-started/regions.md#providers-regions). ### Confluent Cloud - A Confluent Cloud principal with [OrganizationAdmin](../../../../access-control/rbac/predefined-rbac-roles.md#organizationadmin-role) or [AccountAdmin](../../../../access-control/rbac/predefined-rbac-roles.md#accountadmin-role) role binding can create and manage mTLS identity provider resources. The principal must have the required permission to use the certificate authority APIs. - A supported Confluent Cloud cluster type. ### Kafka or Confluent Platform client - mTLS authentication is supported for Kafka and Confluent Platform clients that authenticate to supported cluster types in Confluent Cloud. Schema Registry, ksqlDB, Flink, and Kafka REST APIs are not supported. - Java Client or librdkafka Kafka clients. For supported versions, see [Build Streaming Applications on Confluent Cloud](../../../../../client-apps/overview.md#client-overview). ### Confluent CLI - Confluent CLI 4.4.0 or later. ### mutual TLS (mTLS) authentication - A valid X.509 certificate chain PEM file, used to configure a trusted certificate authority in Confluent Cloud. The PEM file must meet the following requirements: - The CA certificate that signed your client certificates. #### IMPORTANT Public certificate authorities (CAs) are not supported for mTLS authentication for clients connecting to Confluent Cloud. Public CAs are removing clientAuth as a supported Extended Key Usages (EKU) in 2026 which will prevent public certificates from being used for client authentication. - If you want to add a full chain of trust, the CA chain can include a maximum of four certificates. - If using librdkafka clients, the certificate chain must include the signing certificate of the client certificate; otherwise, the TLS handshake fails during mTLS authentication. - Any authenticating librdkafka clients misconfigured with both `SASL_SSL` and `ssl.certificate.location` / `ssl.key.location` configurations fail in an SSL handshake after a Certificate Authority is successfully configured in Confluent Cloud. - Once a Certificate Authority is configured, all supported cluster types in the organization are enabled to use mTLS client authentication. There is no impact on existing API key or OAuth authentication on the same clusters using mTLS. - The file must be named using a `.pem` extension. Example: `acme-internal-client-ca.pem` - A PKCS12 or JKS keystore, used by the client application to authenticate to Confluent Cloud clusters. The keystore must contain the following: - A single client private key. - The client certificate. - The file must be named using a `.p12` or `.jks` extension. PKCS12 example: `acme.client.keystore.p12` JKS example: `acme.client.keystore.jks` - A client configuration file containing the keystore settings for TLS authentication. This file is used by the client application to authenticate to your Kafka clusters. PKCS12 example for `client.properties` ```properties security.protocol=SSL ssl.keystore.location=path/to/.p12 ssl.keystore.type=PKCS12 ssl.keystore.password= ssl.key.password= ``` JKS example for `client.properties` ```properties security.protocol=SSL ssl.keystore.location=path/to/.jks ssl.keystore.type=JKS ssl.keystore.password= ssl.key.password= ``` - Only direct Certificate Revocation Lists (CRLs) are supported, meaning the CRL issuer must be the same as the configured Certificate Authority. CRL URLs support both HTTP and HTTPS protocols, with HTTPS strongly recommended for secure transmission. ## Steps to configure mTLS authentication on Confluent Cloud Follow these steps to configure mTLS authentication on Confluent Cloud. You can use the Confluent Cloud Console, Confluent CLI, or the Confluent Cloud APIs to create a trusted certificate authority (CA) and an identity pool. For the steps below, the examples are based on a hypothetical organization named Acme, Inc. and its internal client applications. 1. Create a trusted CA using the Confluent Cloud Console, Confluent CLI, or the Confluent Cloud APIs. For more information, see [Create a Certificate Authority](certificate-authority.md#create-certificate-authority-mtls). 2. Optional. Use certificate revocation lists (CRLs) to revoke certificates. For details, see [Certificate revocation for mTLS authentication on Confluent Cloud](certificate-revocation.md#certificate-revocation-mtls). 3. Create an identity pool to map a client certificate with a Confluent identity, allowing for [granularity](../../../../../_glossary.md#term-granularity). You can configure varying levels of access for different client certificates issued by your CA to the data within supported cluster types. For details about creating an identity pool for your CA and assigning role bindings for your identity pools, see [Create a certificate identity pool for mTLS](identity-pool.md#create-identity-pool-mtls). 4. Use a valid client certificate for authentication and authorization. Unlike OAuth/OIDC, there is no configuration parameter for the certificate identity pool in the client configuration. The identity pool is automatically mapped based on the identity pool filters. #### IMPORTANT A client certificate can map to multiple identity pools. If multiple pools have filters that evaluate true for the client certificate, then the client is given the union of permissions of all mapped pools. For details, see [Using multiple certificate identity pools](identity-pool.md#multiple-identity-pools-mtls). 5. Verify that the client can authenticate to the cluster with the client configuration file to list topics in the cluster. ## Configuration example Here’s an example of how to use the configured mTLS authentication with a Kafka command-line tool: * Replace with the bootstrap URL for your Kafka cluster. * The client.properties file is the client configuration file that you created in Step 3. It should contain the following settings: PKCS12 example for `client.properties` ```properties security.protocol=SSL ssl.keystore.location=path/to/acme.client.keystore.p12 ssl.keystore.type=PKCS12 ssl.keystore.password= ssl.key.password= ``` JKS example for `client.properties` ```properties security.protocol=SSL ssl.keystore.location=path/to/acme.client.keystore.jks ssl.keystore.type=JKS ssl.keystore.password= ssl.key.password= ``` ```shell # list topics in the cluster bin/kafka-topics.sh --bootstrap-server \ --command-config client.properties \ --list ``` This should return a list of topics in the cluster. Note that you didn’t need to specify the certificate identity pools in the client configuration. Multiple identity pools can be selected based on the filters in the identity pools that evaluate to `true` for the client certificate. The correct identity pools are automatically selected based on the client certificate in the keystore. ## Related content * [Manage Certificate Authorities for mTLS Authentication on Confluent Cloud](certificate-authority.md#manage-certificate-authority-mtls) * [Manage Identity Pools for mTLS Authentication on Confluent Cloud](identity-pool.md#manage-identity-pool-mtls) * [Use Mutual TLS (mTLS) to Authenticate to Confluent Cloud Resources](overview.md#mtls-overview) * [Create CEL Filters for mTLS Authentication](cel-filters.md#create-cel-filters-mtls) * [Troubleshoot mTLS issues](troubleshoot.md#troubleshoot-mtls) * Set up mTLS using Terraform * Use the [confluent_certificate_authority](https://registry.terraform.io/providers/confluentinc/confluent/latest/docs/resources/confluent_certificate_authority) Terraform resource to create, edit, or delete Certificate Authorities on Confluent Cloud. * Use the [confluent_certificate_pool](https://registry.terraform.io/providers/confluentinc/confluent/latest/docs/resources/confluent_certificate_pool) Terraform resource to create, edit, or delete Certificate Pools on Confluent Cloud.