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.
What You Need to Know
An industry-wide change to TLS certificates from Public Certificate Authorities (Public CAs) may affect multi-node KurrentDB clusters and prevent nodes from joining it.
If you are running KurrentDB 24.2 or later and are impacted, upgrade to 24.10.12 or 26.0.2 and apply the recommended configuration changes described in this advisory.
Am I Impacted?
If your KurrentDB cluster is on Kurrent Cloud
You are impacted if:
- You are running KurrentDB 24.2 or later, and
- You are running a multi-node cluster
If you are impacted, follow the resolution steps in this advisory before August 3, 2026.
If your KurrentDB cluster is self-managed or runs on Kurrent Operator
You are impacted if:
- Your node certificates are issued by a public CA, such as Let’s Encrypt, DigiCert, Sectigo, or SSL.com, and
- 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, or
- Certificates that do not use the EKU extension at all
If you are impacted, follow the resolution steps in this advisory before your next certificate renewal. See the appendix for instructions on how to check your certificate.
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.
Symptoms
If your KurrentDB cluster is on Kurrent Cloud
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 AuthenticationIf your KurrentDB cluster is self-managed or runs on Kurrent Operator
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 AuthenticationResolution
If your KurrentDB cluster is on Kurrent Cloud
Log into the Kurrent Cloud management console and initiate the upgrade for your clusters to 24.10.12 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 upgradeIf your KurrentDB cluster is self-managed or runs on Kurrent Operator
- Perform a rolling upgrade of your cluster to 24.10.12 or 26.0.2, with the
DisableClientAuthEkuValidationoption set to true.
For more details, see Disable Client Authentication EKU Validation in the KurrentDB documentation.
- Once all nodes are upgraded and configured, you can safely renew or deploy certificates that have only the
serverAuthEKU.
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
