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.
AWS Region | Location | Enterprise | Dedicated | Freight |
|---|---|---|---|---|
us-east-1 |
| ✓ | ✓ | ✓ |
us-east-2 | Ohio, USA | ✓ | ✓ | ✓ |
us-west-2 | Oregon, USA | ✓ | ✓ | ✓ |
ca-central-1 | Canada Central | ✓ | ✓ | ✓ |
ca-west-1 | Calgary, Canada | ✓ | ✓ | ✓ |
sa-east-1 | São Paulo, Brazil | ✓ | ✓ | ✓ |
AWS Region | Location | Enterprise | Dedicated | Freight |
|---|---|---|---|---|
ap-east-1 | Hong Kong | ✓ | ✓ | ✓ |
ap-northeast-1 | Tokyo, Japan | ✓ | ✓ | ✓ |
ap-northeast-2 | Seoul, South Korea | ✓ | ✓ | ✓ |
ap-northeast-3 | Osaka, Japan | ✓ | ✓ | ✓ |
ap-south-1 | Mumbai, India | ✓ | ✓ | ✓ |
ap-south-2 | Hyderabad, India | ✓ | ✓ | ✓ |
ap-southeast-1 | Singapore | ✓ | ✓ | ✓ |
ap-southeast-2 | Sydney, Australia | ✓ | ✓ | ✓ |
ap-southeast-3 | Jakarta, Indonesia | ✓ | ✓ | ✓ |
ap-southeast-4 | Melbourne, Australia | ✓ | ✓ | ✓ |
ap-southeast-5 | Malaysia | ✓ | ✓ | ✓ |
ap-southeast-7 | Thailand | ✓ | ✓ | ✓ |
AWS Region | Location | Enterprise | Dedicated | Freight |
|---|---|---|---|---|
eu-central-1 | Frankfurt, Germany | ✓ | ✓ | ✓ |
eu-central-2 | Zurich, Switzerland | ✓ | ✓ | ✓ |
eu-north-1 | Stockholm, Sweden | ✓ | ✓ | ✓ |
eu-south-1 | Milan, Italy | ✓ | ✓ | ✓ |
eu-south-2 | Spain | ✓ | ✓ | ✓ |
eu-west-1 | Ireland | ✓ | ✓ | ✓ |
eu-west-2 | London, UK | ✓ | ✓ | ✓ |
eu-west-3 | Paris, France | ✓ | ✓ | ✓ |
AWS Region | Location | Enterprise | Dedicated | Freight |
|---|---|---|---|---|
me-south-1 | Bahrain | ✓ | ✓ | ✓ |
me-central-1 | UAE | ✓ | ✓ | ✓ |
af-south-1 | Cape Town, South Africa | ✓ | ✓ | ✓ |
il-central-1 | Tel Aviv, Israel | ✓ | ✓ | ✓ |
Azure Region | Location | Enterprise | Dedicated | Freight |
|---|---|---|---|---|
canadacentral | Toronto, Canada | ✓ | ||
mexicocentral | Mexico Central | ✓ | ||
brazilsouth | Sao Paulo state, Brazil | ✓ | ||
centralus | Iowa, USA | ✓ | ||
eastus | Virginia, USA | ✓ | ||
eastus2 | Virginia, USA | ✓ | ||
southcentralus | Texas, USA | ✓ | ||
westus2 | Washington, USA | ✓ | ||
westus3 | Phoenix, USA | ✓ |
Azure Region | Location | Enterprise | Dedicated | Freight |
|---|---|---|---|---|
australiaeast | New South Wales, Australia | ✓ | ||
centralindia | Pune, India | ✓ | ||
eastasia | Hong Kong | ✓ | ||
japaneast | Tokyo, Japan | ✓ | ||
koreacentral | Seoul, South Korea | ✓ | ||
southeastasia | Singapore | ✓ | ||
newzealandnorth | New Zealand North | ✓ |
Azure Region | Location | Enterprise | Dedicated | Freight |
|---|---|---|---|---|
francecentral | Paris, France | ✓ | ||
germanywestcentral | Frankfurt, Germany | ✓ | ||
northeurope | Ireland | ✓ | ||
norwayeast | Oslo, Norway | ✓ | ||
swedencentral | Gävle, Sweden | ✓ | ||
switzerlandnorth | Zurich, Switzerland | ✓ | ||
uksouth | London, UK | ✓ | ||
westeurope | Netherlands | ✓ | ||
italynorth | Milan, Italy | ✓ | ||
spaincentral | Spain | ✓ | ||
austriaeast | Vienna, Austria | ✓ |
Azure Region | Location | Enterprise | Dedicated | Freight |
|---|---|---|---|---|
southafricanorth | Johannesburg, South Africa | ✓ | ||
uaenorth | Dubai, UAE | ✓ | ||
qatarcentral | Doha, Qatar | ✓ |
GCP Region | Location | Enterprise | Dedicated | Freight |
|---|---|---|---|---|
northamerica-northeast1 | Montreal, Canada | ✓ | ||
northamerica-northeast2 | Toronto, Canada | ✓ | ||
southamerica-east1 | São Paulo, Brazil | ✓ | ||
southamerica-west1 | Santiago, Chile | ✓ | ||
us-central1 | Iowa, USA | ✓ | ||
us-east1 |
| ✓ | ||
us-east4 |
| ✓ | ||
us-west1 | Oregon, USA | ✓ | ||
us-west2 | Los Angeles, USA | ✓ | ||
us-west3 | Salt Lake City, USA | ✓ | ||
us-west4 | Las Vegas, USA | ✓ | ||
us-south1 | Dallas, USA | ✓ |
GCP Region | Location | Enterprise | Dedicated | Freight |
|---|---|---|---|---|
asia-east1 | Taiwan | ✓ | ||
asia-east2 | Hong Kong | ✓ | ||
asia-northeast1 | Tokyo, Japan | ✓ | ||
asia-northeast2 | Osaka, Japan | ✓ | ||
asia-northeast3 | Seoul, South Korea | ✓ | ||
asia-south1 | Mumbai, India | ✓ | ||
asia-south2 | Delhi, India | ✓ | ||
asia-southeast1 | Singapore | ✓ | ||
asia-southeast2 | Jakarta, Indonesia | ✓ | ||
australia-southeast1 | Sydney, Australia | ✓ | ||
australia-southeast2 | Melbourne, Australia | ✓ |
GCP Region | Location | Enterprise | Dedicated | Freight |
|---|---|---|---|---|
europe-central2 | Warsaw, Poland | ✓ | ||
europe-north1 | Finland | ✓ | ||
europe-southwest1 | Madrid, Spain | ✓ | ||
europe-west1 | Belgium | ✓ | ||
europe-west2 | London, UK | ✓ | ||
europe-west3 | Frankfurt, Germany | ✓ | ||
europe-west4 | Netherlands | ✓ | ||
europe-west6 | Zurich, Switzerland | ✓ | ||
europe-west8 | Milan, Italy | ✓ | ||
europe-west9 | Paris, France | ✓ | ||
europe-west12 | Turin, Italy | ✓ |
GCP Region | Location | Enterprise | Dedicated | Freight |
|---|---|---|---|---|
me-west1 | Tel Aviv, Israel | ✓ | ||
me-central1 | Doha, Qatar | ✓ | ||
me-central2 | Dammam, Saudi Arabia | ✓ |
Confluent Cloud
A Confluent Cloud principal with OrganizationAdmin or AccountAdmin 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.
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_SSLandssl.certificate.location/ssl.key.locationconfigurations 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
.pemextension.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
.p12or.jksextension.PKCS12 example:
acme.client.keystore.p12JKS 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.propertiessecurity.protocol=SSL ssl.keystore.location=path/to/<client-keystore-filename>.p12 ssl.keystore.type=PKCS12 ssl.keystore.password=<keystore password> ssl.key.password=<key password>
JKS example for
client.propertiessecurity.protocol=SSL ssl.keystore.location=path/to/<client-keystore-filename>.jks ssl.keystore.type=JKS ssl.keystore.password=<keystore password> ssl.key.password=<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.
Create a trusted CA using the Confluent Cloud Console, Confluent CLI, or the Confluent Cloud APIs. For more information, see Create a Certificate Authority.
Optional. Use certificate revocation lists (CRLs) to revoke certificates. For details, see Certificate revocation for mTLS authentication on Confluent Cloud.
Create an identity pool to map a client certificate with a Confluent identity, allowing for 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.
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.
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 <bootstrap URL> 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
security.protocol=SSL
ssl.keystore.location=path/to/acme.client.keystore.p12
ssl.keystore.type=PKCS12
ssl.keystore.password=<keystore password>
ssl.key.password=<key password>
JKS example for client.properties
security.protocol=SSL
ssl.keystore.location=path/to/acme.client.keystore.jks
ssl.keystore.type=JKS
ssl.keystore.password=<keystore password>
ssl.key.password=<key password>
# list topics in the cluster
bin/kafka-topics.sh --bootstrap-server <bootstrap URL> \
--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.