[Action Required] Migrate from Public to Private CAs for Confluent Cloud mTLS Authentication by June 2026

Update: The deadline for removal of the clientAuth EKU for Let's Encrypt has been moved to July 8, 2026 for clients using the tlsclient profile before May 13, 2026.

Overview

Initiated by Google Root Program Policy, public Certificate Authorities (CAs) such as DigiCert, Sectigo and Let's Encrypt, are phasing out the ability to use publicly-trusted certificates for client authentication (mTLS).

As early as May 1 2026, public CAs will no longer issue certificates containing the clientAuth Extended Key Usage (EKU) attribute. This change will break mTLS handshakes for any Confluent Cloud clients using newly issued public certificates past the published retirement schedule.

After this change:

• Newly issued public CA certificates will not work for Confluent Cloud mTLS authentication.

• Existing public CA client certificates will continue to work only until they expire.

If your organization uses private CAs (e.g., internal PKI, HashiCorp Vault, Google Cloud CA, AWS Private CA, etc) as your mTLS identity provider, no action is required.

What is changing?

The ability to use a publicly-trusted SSL/TLS certificate for mutual TLS (mTLS) or device authentication is being phased out.

The industry is moving toward a strict "single-purpose" model for certificates:

• Public CAs are intended only to assert public website identities.

• Major browser root programs (led by Google Chrome) now require that public CAs stop issuing certificates for client authentication.

• Practically, this means public CAs must remove the clientAuth EKU from new certificates.

As a result, by mid-2026, public CAs will not be allowed to issue new mTLS‑capable certificates, and any Confluent Cloud client that depends on such certificates will fail to authenticate once it rotates to a new, non‑mTLS‑capable public cert.

Timeline

Most major CAs have already begun their phased rollouts to meet the June 2026 hard deadline set by the Chrome Root Program. Once these dates pass, you will be unable to renew a functional mTLS certificate through these providers.

Who is affected?

If your Confluent Cloud organization uses a public CA, or an intermediate certificate issued by a public CA, as an mTLS identity provider, clients using certificates issued by that public CA will be impacted. This applies to using mTLS authentication with all Confluent Cloud cluster types (dedicated, enterprise, freight).

• Existing Certificates: If you have an unexpired client certificate issued before the end-of-support date that contains a clientAuth EKU, mTLS authentication with Confluent Cloud will continue to work until the certificate expires.

• Certificate Renewals: New client certificates issued or renewed by a public CA will lack the clientAuth EKU required for mTLS.

• Handshake Failure: When a client attempts to connect using a new certificate lacking the clientAuth EKU, the TLS handshake will fail with an unsupported certificate error, causing immediate service disruption.

If your Confluent Cloud organization already uses a private CA (internal PKI, AWS Private CA, HashiCorp Vault, etc.) for mTLS, this ecosystem change does not affect you.

Required action

To ensure continuous service, you must migrate your mTLS identity provider to a private certificate authority before your client applications' next certificate renewal past your public CA’s clientAuth issuance deadline. Moving forward, client authentication must be issued by private CAs, which are not subject to the same clientAuth EKU restriction as public CAs.

The two migration options below assume you have established a private CA and have issued private client certificates for your applications.

Migration options

Option 1: Add Private CA to Existing mTLS Identity Provider Certificate Chain

To reduce identity pool management steps, you may reuse the existing mTLS identity provider representing your public CA by appending your private CA as another accepted chain of trust. Valid client certificates issued by any certificate in the uploaded CA certificate chain may authenticate with the mTLS identity provider.

1. Prepare the Combined Chain: Concatenate your new private CA PEM file to the your existing public CA certificate chain configured as the mTLS identity provider.

   cat public-ca.pem private-ca.pem > combined-ca.pem

2. Verify the formatting: The resulting combined-ca.pem file should contain both blocks with a newline between them.

   -----BEGIN CERTIFICATE-----
   (Public CA data)
   -----END CERTIFICATE-----
   -----BEGIN CERTIFICATE-----
   (Private CA data)
   -----END CERTIFICATE-----

3. Update mTLS Identity Provider: Update the existing mTLS identity provider in Confluent Cloud by re-uploading the combined CA PEM file. This allows Confluent Cloud to trust certificates from both the old and new CAs simultaneously. Refer to the documentation for updating a Certificate Authority.

4. Align mTLS Identity Pools: Ensure the new client certificates issued by the private CA contains metadata that satisfies the existing mTLS identity pool filters for this mTLS identity provider.

   • If you use strict identity pool filters, such as matching specific certificate serial numbers, you will need to modify the identity pool filter to allow both the old public and the new private certificate to use their existing identity pool.

5. Migrate and Restart Clients: Once the client keystore and certificate is updated to the private client certificate, restart your client to pick up the new configurations. Your client will continue to authenticate successfully using the same identity provider and identity pool.

6. Cleanup: Once all clients have rotated, you can remove the Public CA from the PEM bundle and re-upload the Private CA-only file.

Option 2: Distinct mTLS Identity Providers Migration

Duplicate your mTLS identity pools with a new private Certificate Authority identity provider. This approach ensures a clean separation for your new private CA to have distinct certificate identifiers and filters in the new private CA identity pools.

1. Create a New mTLS Identity Provider: Create a new mTLS identity provider and upload the private CA.

2. Create New mTLS Identity Pools: Create new mTLS identity pools for mapping your clients to granular permissions in Confluent Cloud based on the new private certificate metadata (e.g. CN, DN). Ensure the identity pool filter evaluates true for your new private client certificates.

3. Migrate and Restart clients: Once the client keystore and certificate is updated with the private client certificate, restart your clients to pick up the new configurations. Your client will authenticate with the new private CA and automatically map to the new identity pools based on the client certificate metadata.

4. Cleanup: Once all applications have fully migrated off public certificates, you may safely delete the old mTLS identity provider.

While both migration options ensure zero downtime with proper client-side certificate rotation, you should consider the following factors to determine the best approach for your organization:

Need assistance?

If you are unsure whether your current mTLS setup uses a public CA, or you need help on where to configure your Private CA, please contact Confluent Support.