Google finally gets strict about web server certificates – Computerworld

Historically, when companies roll out new capabilities, they start out lenient to encourage usage. Take facial biometrics for example. When they first went into use, the initial settings were chosen to make it easier for the biometrics to work. Yes, it meant more imposters would get a green light, but it sharply limited friction for legitimate users.

Google and many certificate authorities used a similar playbook with web server certificates, allowing them to be used for all kinds of authentication functions instead of just the web server function they were designed for.

That all ends, in theory, on June 15, 2026, according to Google.

The online post explaining the change is quite technical, but the upshot is that Google is finally trying to put an end to the sometimes sloppy way in which certs are being used.

Earlier this year, various groups debated shortening the expiration time frame of web certs to six weeks, a move that was ultimately made official in April. That move dealt with how long web certs could be used. The new Google effort focuses on what they can (and cannot) be used for.

The decision “marks a critical shift in how digital trust is governed and it has serious implications for enterprises, particularly in financial services,” said Timothy Hollebeek, industry technology strategist for DigiCert. The change “will flag such certificates as misconfigured or non-compliant, leading to significant outages for legitimate applications of this EKU. For organizations still using multipurpose certificates, this is a wake-up call. Financial institutions may no longer rely on certificates intended for browsers and web servers.”

Hollebeek argued that this is the right move, given that “many of these applications need no communication outside of the company network and will therefore be more securely protected on an internal PKI, where the organization can configure certificates as they see fit.”

Erik Avakian, a technical counselor at consulting firm Info-Tech, agreed. “Google is actually doing the right thing,” he said. “This is good because it goes back to the concept of least privilege” where certs are used “only for the intended purpose. It’s about zero trust” when “certificates are separated like this.”

Avakian said most users will do whatever is convenient, unless they’re required to do otherwise. “It helps to be forced to do better security,” he said. “Users want to get things done quickly and easily. It comes down to culture, to costs, to ease.”

Hollebeek said the change comes down to using different certificates for server authentication and client authentication. “Cryptographic separation between domains is a well-known security principle,” he said. “You should only be using Web PKI certs if there is a browser involved.”

Another certificate expert, Jason Soroko, agreed with the others that taking the easy route with certs —rather than correct one — is behind this problem.

“Client authentication certificates should be coming from a private certificate authority,” said Soroko, who is a senior fellow at Sectigo. “It was just easier to go to some CA [certificate authority] and get your client authentication.”

The Google statement is written in a language the cert community should certainly understand:

“To align all PKI hierarchies included in the Chrome Root Store on the principle of serving only TLS server authentication use cases, the Chrome Root Program will phase-out multi-purpose roots from the Chrome Root Store. Beginning June 15, 2026, the Chrome Root Program will set an SCTNotAfter constraint on root CA certificates included in the Chrome Root Store for any PKI hierarchy found in violation of the below requirements,” Google wrote. “To reduce negative impact to the ecosystem, the Chrome Root Store may temporarily continue to include a multi-purpose root CA certificate in the Chrome Root Store without an SCTNotAfter constraint on a case-by-case basis, but only if the corresponding CA Owner has submitted a Root Inclusion Request to the CCADB for a replacement root CA certificate before June 15, 2026.”

The upshot? If your operation has been using certs in a lazy, lackadaisical manner, you’ve got less than a year to clean things up.