Follow Cyber Kendra on Google News! | WhatsApp | Telegram

Add as a preferred source on Google

Your TLS Certificates Are About to Silently Break — And You Won't Know Until It's Too Late

Public CAs drop clientAuth EKU from TLS certs in May 2026. If you run mTLS on Apache Kafka, Cassandra, or Pulsar, your next renewal could break.

Certificate Authorities (CAs)

A quiet but consequential change is coming to internet security infrastructure — and unlike most breaking changes, this one won't announce itself until it's already caused an outage.

Starting May 2026, major public Certificate Authorities, including Let's Encrypt, DigiCert, Sectigo, and GlobalSign, will stop embedding the Client Authentication Extended Key Usage (EKU) flag in their publicly issued TLS certificates. 

The CA/Browser Forum — the governing body that sets browser and CA policy — has ruled that client authentication is a private identity concern, unsuitable for public trust infrastructure. The decision is industry-wide and non-negotiable.

For most websites and HTTPS services, nothing changes. The problem falls squarely on organizations running mutual TLS (mTLS) — a security model in which both the server and the client present certificates to verify each other's identities, commonly used in high-stakes distributed systems. 

Apache Kafka, Cassandra, ZooKeeper, Pulsar, Ignite, and Geode all support mTLS as a first-class authentication mechanism, and many production deployments quietly rely on public CAs to issue those client certificates.

The risky part isn't the policy itself — it's the timing. Certificates issued before the May cutoff continue to work until they expire. The failure arrives with the next routine renewal. 

What looks like a stable, fully operational cluster one day becomes an authentication black hole the next, with brokers rejecting clients and cluster members unable to handshake with each other. The certificate will appear perfectly valid in every other respect, making diagnosis genuinely tricky.

Every major TLS library — Java's JSSE, Go's crypto/tls, Rust's rustls, and OpenSSL — enforces the clientAuth EKU check. There's no runtime workaround. The fix requires switching client certificate issuance to an internal or enterprise CA that correctly issues certificates with the required EKU.

Three migration paths exist: run a full internal PKI for both server and client certs; adopt a hybrid model where servers keep public CA certs, but clients move to a private CA; or drop mTLS entirely in favor of application-layer authentication (tokens, OAuth) while retaining standard TLS encryption.

To check if you're exposed, run:

openssl x509 -in your-cert.pem -noout -text | grep -A1 "Extended Key Usage"

If the output shows TLS Web Client Authentication and the cert was issued publicly, your clock is ticking.

The Apache Software Foundation's advice is straightforward: start now. Every certificate renewal in the 12 months following May 2026 is a potential production incident waiting to happen.

Post a Comment