Chrome begins phasing out CA hierarchies not dedicated to TLS

Public TLS certificates are becoming server-only. On 15 June 2026 the Chrome Root Program began phasing out CA hierarchies that serve more than one purpose: under policy v1.8, subordinate CAs newly disclosed to the CCADB must be limited to TLS server authentication. From 15 March 2027, every TLS certificate chaining to a Chrome-trusted root must carry only serverAuth too.

What happened

Chrome now expects roots in its root program to be dedicated to TLS server authentication. Historically, a single root and its intermediates could issue certificates for several uses: TLS servers, TLS clients, email and more. Separating them keeps the needs of other uses from holding back changes to web PKI. The dates:

• 2026-06-15: the phase-out begins. Subordinate CAs disclosed to CCADB from this date must assert only serverAuth in their extended key usage.
• 2027-03-15 (upcoming): subscriber certificates issued on or after this date must include an EKU extension containing only serverAuth, with no clientAuth.

Policy 1.8 sets other dates as well: from 2026-06-15 every TLS precertificate must be logged to at least one Chrome-recognised CT log before the certificate is issued; from 2027-03-15 (upcoming) subordinate CAs must be integrated with an automation solution; and from 2027-09-15 (upcoming) the Chrome Root Store will include at most two root certificates per CA owner. Chrome did not start distrusting leaf certificates that contain clientAuth on 2026-06-15; the leaf-certificate rule applies to certificates issued from 2027-03-15.

The same policy limits root age. Roots whose key material is older than 15 years are removed from Chrome's trust: roots with keys from 2006-2007 around 15 April 2026, and roots with keys from 2008-2009 around 15 April 2027 (upcoming).

Who is affected

Websites that use their certificates only for HTTPS need no action beyond normal renewal. The change falls on three groups:

• Certificate authorities, which must stand up dedicated hierarchies. Let's Encrypt's Generation Y intermediates already omit clientAuth, and Let's Encrypt dropped clientAuth from its default certificates in February 2026.
• Organisations that use public TLS certificates for client authentication in mTLS, such as partner APIs or server-to-server links. As public CAs stop issuing clientAuth, these setups need a private CA.
• Sites on certificates from very old roots. When a root is removed, certificates that chain only to it stop validating in Chrome. CAs normally migrate customers to newer roots or cross-signed paths before that happens.

What you should do

Move anything that relies on clientAuth in a public certificate to a private CA. Start by checking the EKU of the certificates you deploy or present as clients:

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

If anything you run depends on TLS Web Client Authentication in a publicly trusted certificate, plan the move to a private CA before your CA stops issuing it; the clientAuth EKU removed page lists the errors you will see otherwise.

See which root your server's chain ends at:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | grep -E '^ *i:' | tail -n 1

The mTLS guide covers private CA set-ups, the certificate decoder shows EKU and issuer details, and the root program timeline tracks removals and distrust decisions across browsers.