By: Jinwoo Hwang, Lead Developer, Project Lead, and Release Manager, Apache Geode 2.0
What Apache Software Deployers Need to Know Before May 2026
Effective May 2026, major public Certificate Authorities (CAs) will stop including the Client Authentication Extended Key Usage (EKU) in public TLS certificates.
This is not a routine policy update; it is a structural change to how trust is defined on the internet. And for the software ecosystem, it introduces a clear and time-bound risk for deployments relying on mutual TLS. Mutual TLS (or mTLS) is an alternative that verifies identities of both the client and server, rather than just the server as with standard TLS.
Deployers of any Apache project whose deployment relies on mutual TLS (mTLS) with public-CA-issued client certificates — including Apache Kafka, Apache Cassandra, Apache ZooKeeper, Apache Pulsar, Apache Ignite, and Apache Geode — face the same outcome: certificates renewed after this date will no longer include the clientAuth EKU required for client authentication.
Nothing in your code needs to change for this to break. The failure will arrive with a routine certificate renewal, and when it does, it will look like a sudden loss of connectivity across otherwise stable systems. Deployers who rely on the clientAuth EKU need to switch to an internal or enterprise CA.
When Industry Standards Shift Beneath Your Feet
In the evolving landscape of internet security, certificate authorities serve as critical trust anchors. Major public CAs — including Let’s Encrypt, DigiCert, Sectigo, and GlobalSign — are removing the clientAuth EKU from publicly issued-leaf certificates.
This is not a narrow or isolated policy decision. It reflects a coordinated realignment of what a Public Key Infrastructure (PKI) is meant to do. The CA/Browser Forum has concluded that client authentication is a private identity concern and one that should be managed by internal infrastructure, not public trust anchors designed for internet-facing services.
For the broader software industry, and for the Apache ecosystem, this realignment carries immediate operational consequences.
Many widely deployed open source systems (from high-throughput messaging platforms to distributed databases) support mTLS as a first-class mechanism for authenticating clients and cluster members. In practice, many of these deployments have relied on public CAs for convenience.
Because public CAs are removing the clientAuth EKU from their certificates, a single publicly-issued certificate will no longer work for both server and client authentication. Deployers who relied on this convenience will need to source their client certificates separately — typically from an internal or enterprise CA.
The Common Failure Mode Across Apache Deployments
Across the software ecosystem — whether a project is built in Java, Go, Python, C, or Rust — any deployment using mTLS is affected. The TLS libraries in every major language enforce the clientAuth EKU check during client certificate validation. When public CAs stop including that EKU, the handshake will fail regardless of the underlying stack.
When a TLS connection requires client authentication, the TLS stack verifies that the presented certificate includes the clientAuth EKU. If it does not, the handshake is rejected. This is standard behavior across all major TLS implementations — Java (JSSE), Go (crypto/tls), Rust (rustls), and OpenSSL all enforce this check. It is not a quirk of any specific runtime; it is how TLS and X.509 are designed to work, ensuring that a certificate is only accepted for its intended purpose.
Without the clientAuth EKU, mTLS failures will manifest as:
- Brokers rejecting clients
- Cluster members failing to authenticate with each other
- Services losing connectivity despite “valid” certificates
Because every major TLS implementation enforces the clientAuth EKU check, this is not isolated to any single language, runtime, or project — any mTLS deployment using public CA-issued client certificates will be affected.
The fix is not to weaken the TLS check, but to issue client certificates from a CA that includes the correct EKU, such as an internal or enterprise CA. The next section covers exactly when and how these failures will surface.
What Will Break and When
The most dangerous aspect of this change is that failures are delayed.
Deployments will not break when the policy takes effect. They will break when the operator renews their client certificates through a public CA after May 2026. A certificate issued before the cutoff will continue working until it expires. But once it is renewed, the replacement will lack the clientAuth EKU, and the next mTLS handshake will be rejected — even though the previous certificate worked without issue.
This creates a scenario where:
- Deployments appear stable for weeks or months after the policy change
- Routine certificate renewal triggers unexpected outages
- Failures are difficult to diagnose because the certificate looks valid in every other respect
For distributed systems, where certificate rotation is often automated, a single renewal cycle can trigger cascading authentication failures across an entire cluster.
How to Know If You’re Affected
The short answer: if you didn’t explicitly configure mutual TLS (mTLS), you are almost certainly not affected.
Client certificate authentication is not enabled by default in any of the Apache projects discussed in this article. For example, Apache Kafka’s ssl.client.auth defaults to none, and Apache Cassandra ships with client_encryption_options.enabled: false and require_client_auth: false. Standard TLS — where only the server presents a certificate — is the default for Apache Kafka, Cassandra, ZooKeeper, Pulsar, NiFi, and others. Mutual TLS is always an opt-in configuration that someone in your organization would have deliberately enabled. If no one configured mTLS, this change does not affect you.
You are affected if all three of the following are true:
- Your deployment requires clients to present certificates. Look for configuration like ssl.client.auth=required (Kafka), client_encryption_options.require_client_auth: true (Cassandra), or equivalent settings in your project’s TLS configuration.
- Those client certificates were issued by a public CA (e.g., Let’s Encrypt, DigiCert, Sectigo) rather than an internal or enterprise CA.
- Those certificates include the clientAuth EKU today — which they will lose upon renewal after May 2026.
How to check your certificates
Inspect any certificate with OpenSSL:
openssl x509 -in your-cert.pem -noout -text | grep -A1 “Extended Key Usage”
If you see TLS Web Client Authentication, the certificate currently includes the clientAuth EKU. If it was issued by a public CA, it will not include this EKU after renewal.
For Java keystores:
keytool -list -v -keystore your-keystore.jks -storepass changeit | grep -A3 “ExtendedKeyUsages”
If you only use standard TLS (server authentication only), this change does not affect you. Your public CA certificates will continue to work exactly as they do today.
Three Proven Paths Forward
While the problem is broad, the solution space is well understood. Three primary approaches have emerged across Apache deployments.
1) Internal / Enterprise CA for Full mTLS
This approach embraces a simple principle: client identity should be managed internally.
Organizations operate their own certificate authority and issue certificates for both servers and clients, ensuring the correct EKUs are always present.
Why choose this:
- Preserves strong, certificate-based authentication
- Provides full control over certificate lifecycle and policy
Trade-offs:
- Requires PKI infrastructure and operational expertise
- Introduces additional automation and management overhead
2) Hybrid Model: Public CA Servers, Private CA Clients
This model splits trust responsibilities.
- Server certificates remain issued by public CAs
- Client certificates are issued by an internal CA
This preserves external trust for servers while ensuring client certificates include the required clientAuth EKU.
Why choose this:
- Maintains compatibility with systems that rely on public trust stores
- Keeps client identity under organizational control
Trade-offs:
- More complex truststore configuration
- Requires managing two certificate hierarchies
3) Server-Only TLS with Application-Layer Authentication
This approach separates transport security from identity.
TLS is still used to encrypt traffic and authenticate servers, but client identity is handled at the application layer (e.g., passwords, tokens, OAuth).
It is important to note: disabling client certificate authentication does not disable encryption. Data remains fully protected in transit.
Why choose this:
- Simplifies certificate management
- Leverages existing identity systems
Trade-offs:
- Requires robust application-layer authentication
- Moves identity enforcement out of the TLS layer
What You Should Do Now
Regardless of approach, the most important step is to begin planning.
Inventory your environment
- Identify where mTLS is enabled
- Determine which certificates are issued by public CAs
Assess exposure
- Are client certificates used for authentication?
- Are they dependent on public CA issuance?
Test before it matters
- Validate your chosen approach in non-production environments
- Simulate certificate renewal scenarios
Plan for phased migration
- Avoid last-minute changes
- Allow time for validation, rollback, and coordination
A Moment for the Ecosystem
The removal of clientAuth EKU from public certificates is not just a technical adjustment. It is a shift in responsibility.
Client identity is moving out of the public trust layer and back into the hands of the organizations that operate these systems. For the Apache ecosystem, that means rethinking long-standing assumptions about how mTLS is deployed and managed.
The impact is broad because every major TLS implementation enforces the same EKU check. Any mTLS deployment using public CA-issued client certificates will experience the same failure — often at the least convenient moment: certificate renewal.
But the path forward is clear. Whether through private PKI, hybrid trust models, or application-layer authentication, the solutions are well understood and already in use across the ecosystem.
What matters now is acting immediately.
The policy takes effect in May 2026, but the real exposure window extends well beyond that — every certificate renewal over the following 12 months is a potential breakage point. If your next renewal is weeks away, this is urgent. If it’s months away, you have time to plan — but not to postpone. Deployments that begin migrating now can transition deliberately. Those that wait will likely discover this change through a production outage triggered by something as routine as a certificate renewal.
This is an opportunity to modernize how trust and identity are managed across Apache systems.
Where to Get Help
- Check your project’s documentation — Most Apache projects with mTLS support document their TLS configuration. For example, Apache Pulsar’s mTLS authentication guide (https://pulsar.apache.org/docs/next/security-tls-authentication/) walks through the full setup. Start there to understand your current setup and available authentication options.
- Ask on the user mailing list — If you need project-specific guidance, post to your project’s user list (e.g., users@kafka.apache.org, users@nifi.apache.org, users@cassandra.apache.org). The community can help you evaluate which migration path fits your deployment.
- Contact your CA provider — Ask your CA for their specific timeline for removing the clientAuth EKU. For example, DigiCert has announced that on March 1, 2027, it will fully remove the clientAuth EKU from its public TLS certificate issuance process — including renewals, reissues, and duplicates. Your CA may have a different deadline, so confirm when your next renewal will be affected.
