A few weeks ago, I was on a customer call while one of my colleagues ran through the certificate changes coming at the industry. There were six in less than two minutes. One of them came out as: “Google no longer accepts mTLS, so you’re either buying an X9 certificate or managing it privately.”
That was useful shorthand for a busy call, although it was not quite what the policy says. Google is not turning off mTLS. Chrome’s Root Program is changing what it will accept from publicly trusted certificate authorities. The practical result is that certificates used for client authentication need attention now.
The customer contact on the call ran DNS. PKI belonged to somebody else on another team. His concern was straightforward: would the service stay up and answer within the SLA?
Fair question. It also explains why this change is easy to miss. The certificate sits with one team, the relying system sits with another, and the outage eventually lands on whoever is carrying the pager.
What Chrome is changing
A TLS certificate can identify a server, a client, or both. Those permitted uses are recorded in the Extended Key Usage field, usually shortened to EKU. Most public TLS certificates are associated with serverAuth, the use a browser checks when it connects to a website. The EKU at issue here is clientAuth. It is commonly used when a laptop joins a corporate network, a service calls another service, or a partner authenticates to an API with mutual TLS.
Version 1.6 of the Chrome Root Program Policy began separating those uses within Chrome-trusted public TLS hierarchies. Under the current policy, subordinate CA certificates disclosed to CCADB on or after June 15, 2026 must assert serverAuth only. That date passed without an obvious break because the requirement applies to newly disclosed subordinate CAs, not existing subscriber certificates.
The next date operators need to watch is March 15, 2027. Public TLS subscriber certificates issued on or after that date under Chrome-trusted hierarchies must assert serverAuth only. This is an issuance requirement; Chrome is not retroactively distrusting existing certificates simply because they contain clientAuth. DigiCert is moving slightly earlier: on March 1, 2027, it will stop including clientAuth in all newly issued public TLS certificates, including renewals, reissues, and duplicates. Certificates issued before that date will remain trusted until they expire. DigiCert’s transition notice
This is Chrome Root Program policy. It is not a CA/Browser Forum ballot. The Forum’s Baseline Requirements still permit clientAuth. That distinction matters because private PKI is outside the browser root program. If you control the relying party’s trust store, Chrome is not making the decision for you.
Why renewal will not save you
The certificate lifetime schedule is moving at the same time. Public TLS certificates have had a maximum validity of 200 days since March 15, 2026. That falls to 100 days in March 2027 and 47 days in March 2029.
As a result, every public certificate being issued now will renew before the March 2027 policy date. Many will renew twice. That churn helps expose the certificates, but exposure is not migration.
Replacing a certificate takes a few minutes when one team owns both ends and already knows the dependency. That is rarely the setup I encounter. In a real mTLS deployment, somebody has to identify the relying parties, choose the new issuing hierarchy, update trust stores, issue replacement credentials, arrange a test window, and confirm the handshake from both sides. A partner connection adds another company’s change process to the schedule.
If the first time anybody notices clientAuth is during renewal, the certificate team has found the problem too late.
The inventory problem is larger than most teams expect. The 2026 Global PKI Research Report, conducted by Omdia among 423 security leaders at organizations with at least 1,000 employees, found that only a little more than one-third had a complete certificate inventory. Even a complete inventory may record only the issuer, endpoint, and expiration date. None of those fields tells you whether a certificate is being used to authenticate a client.
That is how this policy change becomes a VPN incident, a failed EAP-TLS connection, or a service-to-service outage at 2 a.m. It will look like a network problem first. The certificate may not become the suspect until several teams have already joined the call.
Start with the EKU
The first search is simple. Look for the client authentication OID:
EKU contains 1.3.6.1.5.5.7.3.2 id-kp-clientAuthUse contains, not equals. A certificate carrying both serverAuth and clientAuth is exactly what you need to find. An equality filter drops those dual-purpose certificates and returns a reassuring answer that is wrong.
For the initial pass, include expired and revoked records. An old record may be the only evidence left for a workload whose owner moved on years ago. Search beyond the certificate manager too. I would expect to find relevant material on VPN concentrators and RADIUS servers, in Java keystores, and inside Kubernetes secrets.
I published the longer search specification, including the fields to collect and starter commands for OpenSSL, PowerShell, keytool, and kubectl, here: Finding every client-authentication certificate you own.
Then trace who trusts it
A list of certificates is only the first pass. For each result, identify the system presenting the certificate and every relying party that validates it. Record the owner on both sides, the trust store in use, the issuing chain, and the test needed to prove the replacement works.
This is the part a certificate inventory usually misses. The certificate object does not tell you that three partner APIs trust its chain, or that a VPN profile has the old root pinned, or that a Java service will need a maintenance window before its trust store can change.
The replacement depends on who owns the connection.
Use private PKI when you control both ends
Internal service-to-service authentication, workforce access, and service mesh traffic generally belong here. The relying party uses a trust store you control, so the issuing CA does not need browser trust. For this work, being outside browser policy is useful.
Use Assured ID G2 or G3 to buy time where those chains already exist
DigiCert continues to issue non-browser certificates from these roots while Chrome and Firefox remove their trust for public TLS. In an existing non-browser deployment, that can stabilize the chain while the longer-term design is completed. I would treat it as a bridge and document every dependency before the next move. DigiCert’s root removal details are available here.
Use an industry-governed root when trust crosses company boundaries
ASC X9 launched a common root for financial services in 2025, governed by the ASC X9 Policy Committee and operated by DigiCert. It supports both client and server authentication. DigiCert also identifies manufacturing, healthcare networks, and connected infrastructure as possible uses under the X9 Certificate Policy. More information is available on the X9 PKI page.
Cross-company trust still has to be configured. Each relying party needs the appropriate certificate and must add the X9 root to its trust store. Operating systems and browsers do not ship with that root. Miss one side and the connection fails.
There is a lifetime difference worth including in the design. Current X9 documentation shows a one-year default and a maximum of 397 days. Public TLS is moving from 199 days to 99 and then 46. That may reduce replacement frequency, but it does not remove validation or automation work. Domain validation reuse is tightening there too.
What I would ask the team for
Within two weeks, the team should be able to show you the publicly trusted certificates carrying the Client Authentication EKU and name the relying parties behind them. I would want owners, replacement choices, test plans, and scheduled migration dates for each one.
If producing that list takes more than an afternoon of actual searching, you have learned something important about the inventory. Do not spend the next month polishing the spreadsheet. Start tracing the live dependencies.
Add an EKU check to issuance and renewal so another certificate cannot slip through unnoticed. Treat that check as a guardrail. It is not the migration plan. The replacement certificate and its trust chain need to be deployed, coordinated, and tested before the old certificate reaches renewal.
There is a simple readiness test: can the team name what presents the certificate, what trusts it, who owns both systems, and how they will prove the replacement works?
If the answer is yes, this policy change is manageable. If the answer is “we think we know,” start looking.
Tim McAllister is Regional Field CTO in DigiCert’s Office of the CTO. He works with enterprises and OEMs on PKI, device identity, CRA readiness, and post-quantum migration, particularly where policy turns into an engineering problem.
Tim contributes to standards work involving NIST, SAE EVPKI, Matter, and CharIN. He speaks regularly about changes in PKI, post-quantum cryptography, and AI trust. He also uses AI extensively in his own work, giving him a practitioner’s view of its uses and its limits.
Thanks for reading Tim’s Substack! Subscribe for free to receive new posts and support my work.