Configure Mutual TLS Authentication on Confluent Cloud
To configure Mutual TLS Authentication (mTLS) authentication in Confluent Cloud, you must upload your own Certificate Authority (CA) to your Confluent Cloud organization. This CA is used by Confluent Cloud brokers to validate client certificates presented by your applications. The server’s identity is established using Let’s Encrypt certificates, but client authentication is performed exclusively against your configured CA. This requirement allows you to leverage your existing CA and client certificates, supporting organizations that already use mTLS for secure communication with their applications.
Requirements
The following sections list the requirements for mTLS configuration.
Supported cluster types
The following cluster types support mTLS:
Dedicated clusters
AWS Enterprise clusters with the following considerations:
Limited Availability - to sign up to try mTLS on Enterprise clusters, use this form: Sign up form for Limited Availability with mTLS Enterprise clusters
Certificate revocation lists (CRLs) are not supported for Enterprise clusters at this time. A certificate authority configured with a CRL may be used, however certificate revocation using the CRL will not work for Enterprise clusters.
Organizations that have not been onboarded to the Limited Availability program experience a timed-out response if they attempt to connect to an Enterprise cluster with mTLS authentication.
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.
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 | ✓ | ✓ |
mTLS for AWS Enterprise clusters is a Limited Availability feature in Confluent Cloud.
mTLS for Enterprise clusters is available on AWS in a Limited Availability manner. This is a fully supported offering available in all AWS regions.
To sign up to try mTLS on Enterprise clusters, use this form: Sign up form for Limited Availability with mTLS Enterprise clusters
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 | ✓ | ✓ |
mTLS for AWS Enterprise clusters is a Limited Availability feature in Confluent Cloud.
mTLS for Enterprise clusters is available on AWS in a Limited Availability manner. This is a fully supported offering available in all AWS regions.
To sign up to try mTLS on Enterprise clusters, use this form: Sign up form for Limited Availability with mTLS Enterprise clusters
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 | ✓ | ✓ |
mTLS for AWS Enterprise clusters is a Limited Availability feature in Confluent Cloud.
mTLS for Enterprise clusters is available on AWS in a Limited Availability manner. This is a fully supported offering available in all AWS regions.
To sign up to try mTLS on Enterprise clusters, use this form: Sign up form for Limited Availability with mTLS Enterprise clusters
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 | ✓ | ✓ |
mTLS for AWS Enterprise clusters is a Limited Availability feature in Confluent Cloud.
mTLS for Enterprise clusters is available on AWS in a Limited Availability manner. This is a fully supported offering available in all AWS regions.
To sign up to try mTLS on Enterprise clusters, use this form: Sign up form for Limited Availability with mTLS Enterprise clusters
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 | ✓ |
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 role binding. The principal requires 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 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)
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:
Minimum of one root or intermediate certificate.
Maximum of four certificates in the chain.
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.
Combining multiple authentication methods (for example, OAuth, API keys, and mTLS) for a single cluster is fully supported.
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 associated CA certificate chain that signs 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.
Step 2 - Create an identity pool to map client certificates to granular cluster access
Create an identity pool to map a client certificate with a Confluent identity, allowing for granularity. This enables you to configure varying levels of access for different client certificates issued by your Certificate Authority to the data within supported cluster types.
To create an identity pool for your Certificate Authority and assign role bindings for your identity pools, see Create a certificate identity pool for mTLS.
Step 3 - Verify and use mTLS authentication
After you create a trusted client certificate authority and an identity pool with sufficient permissions, a valid client certificate can be used for authentication and authorization. Unlike OAuth/OIDC, you do not need to specify 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.
To verify that the client can authenticate to the cluster, you can use the client configuration file to list topics in the cluster. Here’s an example of how to use the configured mTLS authentication with a Kafka command-line tool.
Example
To run this example:
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.