Overview
Beginning June 5, 2026, Confluent Cloud is introducing a new require_crl_on_client_certificate attribute on the Certificate Authority (CA) resource used for mTLS client authentication.
Enabling this attribute enables the Certificate Revocation List (CRL) option and enforces a new fail-close check that is aligned with the OpenSSL -crl_check standard. In a fail-close scenario where the CRL is configured, a client certificate will be denied unless it is issued by the same CA that issued the configured CRL. This attribute must be enabled for new CRL configurations.
There is no change in behavior for existing CRL configurations set prior to this change. Existing CRLs retain the previous behavior for backward compatibility — a valid client certificate may still pass authentication even when there is no CRL issuer match. This may be possible since a certificate chain can be configured as the CA. Confluent strongly advises customers using CRLs to migrate to this fail-close enforcement as soon as possible to bring your certificate revocation behavior in line with the OpenSSL standard.
Background
Confluent Cloud supports mutual TLS (mTLS) authentication, where customers bring their own Certificate Authority as a trusted CA identity provider for client connections to the organization. To handle certificate revocation at scale, admins can attach a Certificate Revocation List (CRL) so that any connections made with revoked certificates are rejected. The configured CRL must be issued by a CA in the CA certificate chain.
Under the legacy CRL model, there are two behaviors:
Fail-open on issuer mismatch. If the CRL issuer did not match the issuer of the client's end-entity certificate but could be verified by any of the certificates in the CA chain, the connection could silently pass rather than being denied. This is inconsistent with the OpenSSL
-crl_checkstandard.No explicit control. There was no way to intentionally enable or disable CRL checking — a CRL would be configured automatically, either when a CRL distribution URI was present in the CA, or through explicit configuration.
What Is Changing and Why
A new require_crl_on_client_certificate attribute on the CA identity provider resource gives you explicit, intentional control over CRL enforcement.
When you set require_crl_on_client_certificate to true, Confluent enforces OpenSSL -crl_check behavior:
The client's end-entity certificate is checked against the configured CRL.
The CRL issuer must match the end-entity certificate issuer, or the connection is denied (fail-close).
This makes revocation checks predictable: revoked certificates are denied, and a client certificate and CRL issuer mismatch is surfaced as an explicit authentication failure rather than a silent pass.
Fail-close is now the only model for new CRLs. Any CRL configured after this change follows the OpenSSL -crl_check fail-close behavior — the legacy fail-open model (revoked-only checks, with issuer mismatches passing) is no longer available for new configurations.
Existing CRL configurations continue to operate exactly as they do today, but are treated as legacy behaviors. Existing mTLS connections are not disrupted if the client issuer matches the CRL issuer. The new fail-close behavior takes effect for an existing CRL only after you explicitly set require_crl_on_client_certificate to true.
Who Is Affected
This announcement applies to any Confluent Cloud customer who has configured a CRL on their CA identity provider resource for mTLS client authentication.
If you rely on certificate revocation to manage certificate lifecycle security, opting in ensures revocation checks fail-close and behave consistently with OpenSSL.
If you do not have a CRL configured, no action is required and there is no change to your authentication behavior.
Recommended Action
New CRL configurations are fail-close by default — no action is needed beyond configuring the attribute when you set them up. For existing CRL configurations, Confluent strongly recommends opting into fail-close enforcement to align with the OpenSSL standard. You can configure the require_crl_on_client_certificate attribute via the Confluent Cloud REST API, CLI, or Terraform provider.
To enable fail-close CRL enforcement:
Set
require_crl_on_client_certificatetotrueon your CA identity provider resource.Re-attach your CRL via URL or local file upload (a CRL can only be attached once the attribute is set to
true).Validate that your CRL is issued by the same CA as your client end-entity certificates — an issuer mismatch will now be denied rather than silently passed.
To explicitly opt out of CRL enforcement altogether: set require_crl_on_client_certificate to false. This removes the attached CRL and disables CRL checking.
A few operational notes when enforcement is enabled:
CRL size: total CRL storage is capped at 10 MB per organization across all configured CRLs. Use end-entity CRLs rather than root or intermediate CRLs from large public CAs, which can exceed this limit.
Refresh: URL-based CRLs refresh every 24 hours. If the URL is unreachable at refresh time, the last successfully fetched CRL is used. Trigger a manual refresh by updating the CA identity provider resource.