# Use Mutual TLS (mTLS) to Authenticate to Confluent Cloud Resources You can use mutual TLS (mTLS) for X.509 client certificate authentication and granular access control to access supported cluster types in your Confluent Cloud organization. Confluent Cloud allows you to use mTLS with Kafka clusters and Confluent Platform clusters. To use mTLS authentication with Confluent Cloud, you must upload and configure your own Certificate Authority (CA) in your Confluent Cloud organization. This CA is used by Confluent Cloud brokers to validate client certificates during authentication. Confluent Cloud uses Let’s Encrypt certificates for its own identity, but client authentication is performed against the CA that you configure in your Confluent Cloud organization. ## Key benefits * **Enhanced security**: mTLS provides a higher level of security by requiring both the client and server to authenticate each other. This two-way authentication significantly reduces the risk of unauthorized access. * **Strong access control**: It makes it much more difficult for unauthorized users or systems to connect to the Confluent Cloud resources, as they would need valid certificates. * **Compliance**: Many industries have strict regulatory requirements for data protection and access control. mTLS can help meet these compliance standards by providing strong authentication. * **Protection against attacks**: mTLS helps prevent man-in-the-middle attacks and other common security threats by helping to ensure that both parties in the communication are who they claim to be. * **Data integrity and confidentiality**: The encryption provided by TLS, combined with the mutual authentication, ensures that data in motion (or data in transit) is protected from tampering and eavesdropping. * **Client-side security**: It enforces security at the client level, to help ensure that only authorized clients with valid certificates can connect to Confluent Cloud resources. * **Reduced reliance on passwords**: mTLS can be used as an alternative or supplement to traditional username/password authentication, potentially reducing the risks associated with password-based security. * **Granular access control**: Certificates can be issued and managed for specific clients or applications, allowing for more [fine-grained control](../../../../../_glossary.md#term-granularity) over who can access what resources. ## How mTLS works in Confluent Cloud Here’s a summary of the mTLS handshake process in Confluent Cloud: 1. Client initiation: The client initiates a TLS connection to your Confluent Cloud cluster. 2. Server hello: The Confluent Cloud cluster responds and requests the client’s certificate. 3. Client certificate: The client sends its certificate to the cluster, allowing the cluster to verify the client’s identity. 4. Server authentication: The Confluent Cloud cluster presents Let’s Encrypt certificates to the client for verification. 5. Certificate verification: Both the client and server verify each other’s certificates: - The Kafka client verifies the cluster’s certificate. For more information, see [Manage TLS certificates](../../../../../client-apps/client-configs.md#manage-tls-certificates). - The Confluent Cloud cluster verifies the client’s certificate. The cluster verifies the client certificate against the configured Certificate Authorities (CAs) that the administrator set up ahead of time in the Confluent Cloud organization. 6. Secure connection: After the TLS handshake is successful, the Confluent Cloud cluster must identify the certificate identity principals that match the client certificate metadata for authorization. At least one certificate identity pool must match, otherwise there is an authorization error. If any step in this process fails, the connection attempt is terminated. By implementing mTLS, Confluent Cloud ensures that all communication between your clients and Confluent Cloud resources is not only encrypted but also authenticated, providing a robust defense against unauthorized access and data breaches. ## Key components of mTLS in Confluent Cloud Customer-provided Certificate Authority (CA) : To enable mTLS authentication, you must upload your own CA to your Confluent Cloud organization. This CA is used by Confluent Cloud brokers to verify the identity of connecting Kafka clients. This approach allows you to use your existing PKI infrastructure and client certificates, ensuring seamless integration with your organization’s security architecture. Certificates : Both the client and the server must have their own certificates, which are used during the handshake process to prove their identities to each other. Certificate Authority (CA) : A trusted CA is responsible for issuing and verifying the digital certificates used in the mTLS process. For client authentication, Confluent Cloud uses the CA that you upload and configure in your organization. The Confluent Cloud cluster uses Let’s Encrypt for its own identity, but uses the CA that you configure to validate the clients. Client certificates : Clients need to present a valid certificate that is either self-signed or signed by a trusted CA. This certificate must be configured in the client’s application or service that connects to Confluent Cloud. TLS Handshake : This is the process where the client and server exchange certificates and validate each other. If either party fails to authenticate the other, the connection is not established. Encryption : After a successful handshake, all data transmitted between the client and server is encrypted using TLS, providing confidentiality and integrity. ## Implementation considerations Certificate management : Managing certificates and keys securely is crucial. This includes issuing, renewing, and revoking certificates as needed. Performance : The mTLS handshake can add latency to the initial connection setup. It’s important to consider this in performance-sensitive applications. Compatibility : Ensure that all parts of your system are compatible with mTLS and can handle the requirements for certificate management. ## Related content * [Configure Mutual TLS (mTLS) Authentication](configure.md#configure-mtls) * [Create CEL Filters for mTLS Authentication](cel-filters.md#create-cel-filters-mtls) * [Troubleshoot mTLS issues](troubleshoot.md#troubleshoot-mtls) * [Manage Certificate Authorities for mTLS](certificate-authority.md#manage-certificate-authority-mtls) * [Manage Identity Pools for mTLS](identity-pool.md#manage-identity-pool-mtls)