The clientAuth EKU Removal: Why Public TLS Certificates No Longer Authenticate Clients

What changed with the clientAuth EKU?

Publicly trusted TLS certificates may now assert only one purpose: server authentication. The extended key usage extension in an X.509 certificate lists what the certificate is permitted to do, and for years many public certificates listed two values — id-kp-serverAuth and id-kp-clientAuth — which meant the same certificate could be presented by a server proving its domain, or by a client proving itself to a server. The second value is gone from new public issuance. Only the first remains.

The requirement lives in the Chrome Root Program Policy, version 1.8 as of February 5, 2026. Subscriber certificates — the ones on your server — must include the extended key usage extension and assert only id-kp-serverAuth. For the intermediates above them the rule carries a date: a subordinate CA disclosed to the Common CA Database before June 15, 2026 may assert serverAuth alone or serverAuth together with clientAuth, while one disclosed on or after that date may assert serverAuth alone. From June 15, 2026 the program also began phasing out hierarchies found in violation, with the phase-out date set 90 days after a violation is detected.

That distinction between subscriber certificates and subordinate CAs is worth holding onto, because a lot of write-ups collapse it into "Chrome blocks dual-EKU certificates on June 15." The practical effect is close enough for planning purposes, and the mechanism matters when you are reading your own chain: the constraint propagates downward from which intermediate you were issued under. If you want a refresher on where this extension sits in the structure, our guide to X.509 fields and extensions covers the layout.

Why was client authentication removed from public TLS certificates?

Because a public CA never verified the claim that a client certificate makes. When a certificate authority issues a TLS certificate it checks one thing about identity: that the applicant controls the domain name going into the certificate. That check supports the server-side claim perfectly — the server says it is example.com, and the CA confirmed somebody proved control of example.com. It supports the client-side claim not at all. Nothing in domain validation establishes that the holder is an authorised client of anything.

The consequence was a quiet structural weakness. Any system that accepted client certificates from the public trust store was, in effect, accepting an identity assertion that no CA had ever examined. An attacker who obtained a perfectly legitimate certificate for a domain they genuinely controlled held a valid credential that chained to a trusted root, and a permissive verifier had little basis to reject it. The Chrome Root Program's broader position is that hierarchies in its store should serve TLS server authentication and nothing else, so that the risk a root carries can be reasoned about; the same reasoning has been driving multi-purpose roots out of the store through 2026.

None of that means the systems relying on public client certificates were badly built. It was a reasonable use of an available feature, and the feature was available for a long time. The judgement that changed is about what a public root should be asked to underwrite, and that judgement was made by the parties who decide what browsers trust.

Which dates actually matter?

Four dates, and they do different things. In late 2025 the major CAs stopped including clientAuth by default while still honouring requests for it: Sectigo from September 15, 2025 and DigiCert from October 1, 2025. Issuance then stopped outright — DigiCert on May 1, 2026, and both Sectigo and Certum on May 15, 2026. Chrome's dated requirement for newly disclosed subordinate CAs took effect on June 15, 2026. Everything after that is expiry, not policy.

The reason the default-off dates matter more than they look is that they are where the silent replacements began. An organisation that renewed a dual-purpose certificate in, say, November 2025 without explicitly requesting clientAuth received aserverAuth-only certificate and may have discovered the difference in production. If you had an unexplained mTLS failure in the last three quarters, this is a strong candidate for what caused it.

How long do existing dual-EKU certificates keep working?

Until they expire, and that is sooner than most migration plans assume. Certificates issued with clientAuth before each CA's cutoff remain valid and accepted for the rest of their lifetime — Certum states this explicitly for the certificates it issued up to May 15, 2026. Nothing revokes them and no browser update kills them early. The limit is arithmetic rather than policy.

Since March 15, 2026 the maximum validity of a publicly trusted TLS certificate has been 200 days, under the schedule the CA/Browser Forum adopted in Ballot SC-081v3 (many CAs issue at 199 days to leave margin). The last certificate anyone could obtain with clientAuth was issued on May 15, 2026. Add 200 days to that date and you land on approximately December 1, 2026. Certificates from DigiCert's earlier cutoff run out around two weeks before that.

Am I affected?

Only if something you run presents a publicly issued certificate in order to prove its own identity to another system. That is a narrower group than the coverage suggests. A web server serving HTTPS to browsers is not affected. An API that only answers requests is not affected. A load balancer terminating TLS on the way in is not affected. The affected pattern is the reverse direction, and it usually appears in one of a handful of places.

In practice the credential turns up in server-to-server API calls where a partner required a certificate instead of a token; in payment and banking integrations that specified a publicly trusted client certificate in their onboarding documents; in device fleets enrolled years ago against a public CA; and in VPN or gateway configurations where the same wildcard certificate was reused for both ends because it was already on the box. If you want the background on how the handshake uses these credentials, our explainer on mutual TLS walks through both directions of the exchange.

Enterprise Wi-Fi is the case people expect to be caught by this and mostly are not. EAP-TLS client certificates have always come from an internal CA, because a public CA never had a way to verify that a laptop belonged to your estate; our guide to which RADIUS and EAP-TLS certificates you buy and which you issue sets out why the server half of that handshake is untouched by the change.

The awkward case is the third-party one: your partner's gateway demands a publicly trusted client certificate and their documentation has not been updated. You cannot fix that with a purchase, because no CA can sell you what they are asking for. That conversation has to happen with them, and it is better had now than in the week their integration stops.

How do I check whether a certificate has the clientAuth EKU?

Read the extended key usage extension directly. For a certificate file on disk, one command answers it:

openssl x509 -in client.pem -noout -ext extendedKeyUsage

A certificate that can still do the job prints both purposes:

X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication

One that cannot prints TLS Web Server Authentication alone. To check what a live endpoint is actually presenting rather than what you believe is deployed, pipe a connection into the same command:

openssl s_client -connect api.example.com:443 -servername api.example.com \
  </dev/null 2>/dev/null | openssl x509 -noout -ext extendedKeyUsage

Run this against every certificate in inventory rather than the ones you suspect. The whole difficulty of this migration is discovery: the certificate that will break is usually the one nobody remembers deploying. Our OpenSSL commands cheat sheet has the inspection syntax for the other formats you will hit, and the free SSL checker is quicker when what you need is what a public hostname is serving right now.

What does the failure actually look like?

A rejection at certificate verification, not a handshake or trust error, which is what makes it confusing to diagnose. The certificate chains correctly, its dates are fine, its signature validates, and the connection still fails — because the verifier got as far as checking what the certificate is permitted to do and found the wrong purpose. Error text varies by stack, and two messages come up repeatedly.

OpenSSL-based verifiers report an unsupported certificate purpose (X509_V_ERR_INVALID_PURPOSE). Java's JSSE is more explicit, raising a ValidatorException stating that extended key usage does not permit use for TLS client authentication. An Nginx server with ssl_verify_client on will typically return a 400 with a certificate error rather than anything describing the EKU. In each case the giveaway is the same: everything about trust checks out and the certificate is refused anyway.

This is worth stating plainly because the instinct when an mTLS connection fails is to suspect the chain, the trust store, or a clock. Those are the usual causes and they are not this one. If the certificate presented by the client was reissued recently and the error mentions purpose or key usage, stop debugging trust — trust store differences produce a different class of error entirely.

How do I move client authentication to a private CA?

Issue the client credential from a certificate authority you control, and leave the server side exactly as it is. The replacement is a private CA — an internal issuing authority whose root you install on the systems that need to verify your clients. Nothing about this is a downgrade for machine-to-machine authentication, because the property you lose is universal browser trust and browsers were never party to the connection.

The practical sequence is short. Inventory every certificate presented as a client credential, using the commands above. Stand up an issuing authority — a managed private CA from a cloud provider, an internal PKI, or for a small and stable set of peers, a self-signed root you generate and guard properly; our guide to self-signed certificates covers where that is defensible and where it is not. Issue client certificates with clientAuth and no serverAuth. Add the private root to the trust configuration of each verifying service, keeping it scoped to client verification rather than adding it to the system-wide store. Then cut over, confirm, and remove the public certificate from the client.

Two details cause most of the pain. Verifying services frequently accept client certificates from whatever is in the default trust store, which means adding your private root without scoping it leaves the old permissive behaviour in place — worth fixing during the migration rather than after. And private CAs let you set your own lifetimes, which is a genuine advantage over a public certificate now capped at 200 days, but only if the renewal is automated; a five-year client certificate with no rotation mechanism is a problem deferred, not solved.

Your server certificates carry on unchanged through all of this. They assert serverAuth, that is the purpose that survived, and renewing them needs no special handling — a standard publicly trusted SSL/TLS certificate is still exactly the right product for anything a browser or an external client connects to. The split this change forces is between two jobs that were always distinct; only the packaging pretended otherwise.