Google Chrome is tightening its certificate trust rules. Starting June 15, 2026, Chrome will stop trusting publicly trusted server SSL/TLS certificates that include the client authentication Extended Key Usage, commonly shown as clientAuth EKU. For most websites, nothing changes. Standard HTTPS certificates used strictly for server authentication should continue working normally. The impact falls on organizations that have been using public certificates for client authentication, often in mutual TLS (mTLS) setups where a certificate is used not only to encrypt traffic, but also to prove a user, device, or application’s identity.
If your environment depends on client certificates issued from a public CA, this is the moment to plan ahead. Even though the enforcement date is in 2026, certificate authorities and platform vendors often adjust issuance behavior earlier, and renewals tend to surface problems before a hard deadline ever arrives. Waiting increases the odds of an unexpected break in authentication flows, especially in production systems with tight uptime requirements.
What’s changing, and why Chrome is doing it
Certificates include “intent” fields that describe what they are allowed to be used for. Extended Key Usage (EKU) is one of those fields. A typical public web certificate is meant for server authentication, which enables browsers to confirm they are talking to the right website over HTTPS. Some certificates were issued with both serverAuth and clientAuth, making them usable in more than one scenario. Chrome’s policy direction is to keep the public Web PKI focused on the browser’s core job: protecting users when they connect to websites. Client authentication is a different trust model, with different lifecycle, distribution, and revocation expectations, and it is better handled through private trust that an organization controls.
This shift does not mean Chrome is “turning off mTLS.” Mutual TLS can still be used, but the expectation is that client certificates should come from a PKI designed for client identity, such as an internal enterprise CA or a managed private CA, rather than the public trust system browsers rely on for the open web. Practically, it is a separation-of-duties move: public trust for servers, private trust for clients.
Who’s impacted, and what to do before June 2026
You are most likely impacted if you use publicly trusted certificates to authenticate clients in workflows like device identity for internal applications, partner integrations that rely on mTLS, API-to-API authentication, gateway access controls, or any setup where a client certificate gates access to sensitive systems. The smartest path forward starts with visibility: inventory where client certificates are used, which CA issues them, and which systems validate them. Then confirm certificate profiles and flag anything that includes clientAuth EKU in a publicly trusted chain. From there, migrate client authentication to a private PKI that you control, update the relevant trust stores (devices, apps, gateways, and services), and validate that enrollment, rotation, and revocation processes work end to end. Finally, test early, especially renewal and reissue flows, because that’s where policy changes tend to show up first. Coordinating with software vendors is also key if third-party tools handle certificate validation or provisioning.
Handled proactively, this is a manageable transition. If ignored, it can turn into a sudden authentication outage that is far harder to troubleshoot under pressure. Treat June 15, 2026 as the hard stop, then work backward to complete discovery, migration, and testing well before that date.
