Applies to: KurrentDB version 24.2 and later*
Addressed in: KurrentDB version 24.10.12 and 26.0.2

* Note: While versions older than 24.2 are not impacted, we strongly recommend upgrading directly to the latest LTS patch version to ensure continued compatibility.

Overview

An important industry-wide change to TLS certificates may affect your KurrentDB clusters.

Public CAs are moving away from issuing TLS certificates with the clientAuth Extended Key Usage (EKU), which KurrentDB 24.2+ requires when running in a cluster. Nodes configured with such a certificate following renewal may not be able to join the cluster, potentially causing a disruption in service,

For KurrentDB self-managed or Kurrent Operator deployments:

• This can happen after your next public CA certificate renewal.

For Kurrent Cloud customers:

• This can happen after Kurrent Cloud migrates to the new certificate profile, on August 3rd 2026.

Affected clusters must upgrade and be configured with DisableClientAuthEkuValidation before being given a certificate that lacks the clientAuth EKU.

See details below.

Background

Major public CAs are removing the clientAuth Extended Key Usage (EKU) from TLS server certificates, in compliance with the Google Chrome Root Program policy v1.8. Some CAs have already made this change (See appendix).

For KurrentDB versions 24.2 and higher, node certificates are required to include both the serverAuth and clientAuth Extended Key Usages (EKUs), or to omit the EKU extension entirely, in accordance with RFC 5280 section 4.2.1.12.

This requirement exists because KurrentDB nodes use their certificates for two purposes: accepting incoming connections and authenticating when connecting to other nodes in the cluster.

Certificates issued by public Certificate Authorities (CAs) that exclude clientAuth will be rejected during inter-node communication, which will prevent those nodes from successfully joining the cluster.

KurrentDB 24.10.12 and 26.0.2 introduce a new configuration option that allows nodes to accept certificates without the clientAuth EKU, so that customers can continue using public CA certificates.

Am I Impacted?

For Self-managed KurrentDB and Kurrent Operator Deployments

You ARE impacted if

• Your node certificates are issued by a public CA (e.g., Let’s Encrypt, DigiCert, Sectigo, SSL.com, etc.).
• You are running KurrentDB 24.2 or later, and
• You are running a multi-node cluster

You are NOT impacted if your node certificates are:

• Issued by your own private CA, or
• Self-signed certificates, or
• Certificates that do not use the EKU extension at all (see appendix for instructions to check)

For Kurrent Cloud Deployments

You ARE impacted if

• You are running KurrentDB 24.2 or later, and
• You are running a multi-node cluster

Symptoms

For Self-managed KurrentDB and Kurrent Operator deployments

When the KurrentDB node is updated with a certificate that lacks the clientAuth EKU and tries to join a cluster, it will fail. Other nodes in the cluster will log the following error:

Connection from node: <address> was denied because it is not configured as a server certificate: Missing extended key usage: Client Authentication

For Kurrent Cloud Deployments

After Kurrent Cloud migrates to the new certificate profile on August 3rd 2026, when a KurrentDB node tries to join a cluster, it will fail. Other nodes in the cluster will log the following error:

Connection from node: <address> was denied because it is not configured as a server certificate: Missing extended key usage: Client Authentication

Resolution

For Self-managed KurrentDB and Kurrent Operator deployments

1. Perform a rolling upgrade of your cluster to 24.10.12 or 26.0.2, with the DisableClientAuthEkuValidation option set to true.

For more details, see Disable Client Authentication EKU Validation in the KurrentDB documentation.

2. Once all nodes are upgraded and configured, you can safely renew or deploy certificates that have only the serverAuth EKU.

For Kurrent Cloud

Log into the Kurrent Cloud management console and initiate the upgrade for your clusters to 24.10.2 or 26.0.2.

Note: No manual change to the DisableClientAuthEkuValidation config is required on your part. It will be applied automatically as part of the upgrade

Security considerations

Setting DisableClientAuthEkuValidation to true disables one specific check: verification that an inbound node certificate contains the clientAuth EKU. All other certificate validation continues to apply, including chain of trust, expiry, common name, and key usage.

In practice, the risk is small for most deployments. It is completely safe for Kurrent Cloud. The clientAuth EKU serves as an additional constraint ensuring that a certificate was explicitly issued for client authentication purposes. Without this check, any certificate that passes all other validation criteria — including being signed by a trusted CA and matching the expected common name — would be accepted for inter-node communication, even if it was only intended for server authentication.

Customers whose PKI policy relies on the distinction between serverAuth-only and clientAuth certificates as a security boundary should evaluate whether this relaxation is acceptable for their environment.

Support

If you have any questions or need assistance:

What’s coming next

A future release of KurrentDB will introduce a dual-certificate model, allowing you to configure separate certificates for inbound connections (no clientAuth, public CA) and outbound node-to-node connections (clientAuth, private CA). This will eliminate the need for the DisableClientAuthEkuValidation workaround while remaining fully compliant with RFC 5280. More details will follow as development progresses.

Appendix

CA Removal Timeline

The following is a sample of public CAs that have announced dates for removing clientAuth from TLS server certificates. Other public CAs are expected to follow. Check with your CA to confirm when this change will be enforced.

For CAs with a default and hard deadline: certificates issued between those dates may or may not include clientAuth depending on your account profile or certificate request configuration. After the hard deadline, clientAuth will not be included under any circumstances. Some providers are extending their hard deadlines into 2027 after Google recently extended the deadline in the root program requirements.

How to Check your Certificate

Run the following command to inspect the EKUs on your node certificate:

openssl x509 -in /path/to/node.crt -noout -text | grep -A1 "Extended Key Usage"

If the output includes both TLS Web Server Authentication and TLS Web Client Authentication, your certificate is compatible and no action is needed.

If the output shows only TLS Web Server Authentication, your certificate is missing clientAuth and you need to follow the resolution steps below.

References

• Google Chrome Root Program policy
• SSL.com: Removal of the Client Authentication EKU from TLS Server Certificates
• DigiCert: Sunsetting clientAuth EKU
• Let’s Encrypt: Ending TLS Client Authentication
• Sectigo: TLS Client Authentication Changes
• KurrentDB: Protocol Security Documentation
• KurrentDB: Upgrade Guide — Certificate Requirements
• KurrentDB: Disable Client Authentication EKU Validation