Abstract
Chrome’s root program decides what certificates will be trusted by Chrome, and what they are allowed to do. Recently, Google decided that client authentication isn’t on the list. Under Chrome Root Program Policy v1.8, every certificate issued on or after March 15, 2027 can assert only one Extended Key Usage (EKU): server authentication.
Let’s Encrypt moved early. They dropped the client authentication extension from their default profile on February 11, 2026, left a tlsclient profile open for anyone who needed more time, but shut that down on July 8. Their certificates are valid for 90 days, so the last client certificates they will ever issue expire in the first week of October. The commercial CAs are implementing similar timelines.
If you’re using public certificates for mTLS client authentication, you have a few weeks to figure out a new way to handle it. Nothing is broken today. The certificates you already have keep working until they expire, but there is no renewal waiting behind them. That new way is probably a private PKI.
What the EKU actually does
A certificate isn’t inherently a server certificate or a client certificate. The Extended Key Usage extension specifies that with a short list of what the key is allowed to be used for. id-kp-serverAuth (OID 1.3.6.1.5.5.7.3.1) means this certificate can prove it’s the server you asked for. id-kp-clientAuth (1.3.6.1.5.5.7.3.2) means it can prove it’s the client connecting in. There are other EKUs for code signing, email protection, and time stamping.
Public CAs put both serverAuth and clientAuth in every certificate for years. So one certificate could do both jobs.
Chrome’s reasoning is one sentence in the policy: “The Chrome Root Store is solely relied upon for TLS server authentication in Chrome; it is not used for any other PKI use case.” The store does one job, so the certificates under it should do one job. Client authentication has been riding along in a trust store built for something else.
The enforcement didn’t come from the CA/Browser Forum. This is a root program requirement, meaning Google acted alone. It’s the same move the browsers made on certificate lifetimes, where Apple went around the Forum and the CAs ratified it afterward. The Forum votes on the rules. The browsers decide what’s in the trust store, which turns out to be the part that matters.
A number of write-ups on this credit ballot SC-081v3, which is incorrect. That ballot is the validity and data reuse schedule, the one that takes certificates to 47 days. Different rule, different problem.
ClientAuth EKU is for mutual TLS (mTLS)
In regular TLS, only the server proves identity. The client validates that certificate, but stays anonymous.
The difference between TLS and mTLS is that mutual TLS checks both identities. The server sends a CertificateRequest, and the client answers with its own certificate and a CertificateVerify signature over the handshake. The client certificate is doing certificate-based authentication, instead of the API key or password that would be used otherwise, and requires the id-kp-clientAuth EKU.
mTLS authentication shows up in more places than people expect. Banks and payment processors require it on partner API connections. Some microservice architectures authenticate every call between services with a client certificate. Device fleets, VPN concentrators, and 802.1X wireless all identify endpoints the same way. And a lot of vendor appliances were shipped with instructions that said to install a public certificate, without mentioning which half of it was doing the work.
Cisco has filed field notices on this for Unified Border Element, Expressway, and Secure Network Analytics. The Expressway notice lists what stops working: SIP business-to-business calls, federation, traversal zones, and cloud connectivity. Their permanent fix ships in Expressway X15.5. Everyone running anything older gets to fix it themselves.
Cisco’s first suggested workaround is to find a CA that still issues both extensions. That buys you months, not years. Maximum certificate validity dropped to 200 days on March 15, 2026, DigiCert turned the extension off by default back in October 2025 and removes it entirely on March 1, 2027, and the Chrome deadline lands two weeks after that. Every public path out of this closes by March 2027.
You actually need private PKI for this
For internal servers, I’ve argued that you don’t actually need private PKI. DNS validation gets you a publicly trusted certificate, even if the host isn’t reachable from the internet. It saves you having to maintain and secure your own root CA, which adds a lot of complexity to overworked IT shops.
Client certificates don’t have a public option anymore. If you need machines to prove their identity to each other, you run the CA that issues those certificates. Let’s Encrypt said as much in their own announcement: client authentication is better served by a private certificate authority.
That means taking on the work the public CA was doing for you. You decide the lifetime. You get your root onto every client that has to trust it. You run revocation that actually works, which is harder than the public web PKI makes it look. And you keep track of what certificates exist, because a private CA with no inventory is just an outage with a longer clock.
If you’re not sure how to handle this, you should probably subscribe to our newsletter. We’re working on something that will make your private PKI easier to deploy.
CertKit automates certificate lifecycle management for your public certificates, and we’re working on the private ones.
Comments