# Chrome begins phasing out CA hierarchies not dedicated to TLS

> Chrome Root Program Policy v1.8: from 2026-06-15 new subordinate CAs must be serverAuth-only; from 2027-03-15 leaf certificates must be too.

Source: https://ssl.sh/news/chrome-dedicated-tls-hierarchies/
Last updated: 2026-11-10

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](https://ssl.sh/glossary/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](https://ssl.sh/glossary/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](https://ssl.sh/glossary/subordinate-ca/) disclosed to CCADB from this date must assert only `serverAuth` in their [extended key usage](https://ssl.sh/glossary/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](https://ssl.sh/glossary/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](https://ssl.sh/news/lets-encrypt-generation-y-hierarchy/) intermediates already omit clientAuth, and Let's Encrypt [dropped clientAuth](https://ssl.sh/news/lets-encrypt-ends-tls-client-authentication/) from its default certificates in February 2026.
- **Organisations that use public TLS certificates for client authentication** in [mTLS](https://ssl.sh/glossary/mtls/), such as partner APIs or server-to-server links. As public CAs stop issuing clientAuth, these setups need a [private CA](https://ssl.sh/glossary/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:

```bash
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](https://ssl.sh/errors/client-auth-eku-removed/) page lists the errors you will see otherwise.

See which root your server's chain ends at:

```bash
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](https://ssl.sh/learn/mtls/) covers private CA set-ups, the [certificate decoder](https://ssl.sh/tools/certificate-decoder/) shows EKU and issuer details, and the [root program timeline](https://ssl.sh/timeline/root-program-changes/) tracks removals and distrust decisions across browsers.