# Public SSL certificates no longer include client authentication

For years, a certificate bought for a web server could also prove a
server's identity when it connected to another server as a client. That
worked because public certificates carried two purposes (extended key
usages, EKUs): **server authentication** and **client authentication**. The
second one is going away, and setups that relied on it fail when the next
renewed certificate arrives without it.

## Why it's happening

Google's Chrome Root Program now accepts certificate hierarchies used only
for TLS server authentication. Its policy says subscriber certificates
issued from **15 March 2027** may assert only server authentication, and
new intermediate CAs disclosed from 15 June 2026 must already be
server-only. CAs moved earlier, each on its own schedule.

## When each CA dropped it

| CA | Change |
|---|---|
| Let's Encrypt | Removed from the default profile on **11 February 2026**; the opt-in `tlsclient` profile ended **8 July 2026** |
| Sectigo | Removed by default from 14 October 2025; no exceptions after **15 May 2026** |
| DigiCert | Removed by default from 1 October 2025; available on request until **1 March 2027**, including renewals and reissues |

Certificates already issued keep both purposes until they expire. The
problem appears at the **first renewal after the cut-off**, which can be
months after the CA's announcement.

## What breaks

Anything that uses a public TLS certificate as a **client** certificate,
where the other side checks it's allowed for client authentication:

- **Server-to-server mutual TLS**: APIs and integrations where both sides
  present public certificates.
- **Cisco Expressway** business-to-business and federation connections.
  Cisco published field notice FN74362 about it; Expressway releases X14.0.0
  to X14.3.7 and X15.0.0 to X15.3.2 are listed as affected.
- **Any appliance or service** documented as "use your public certificate
  for both inbound and outbound TLS".

The symptom is a TLS handshake that fails on the outbound connection right
after a renewal, with errors such as "unsupported certificate purpose" or
"certificate not valid for client authentication", while the website on the
same certificate works fine.

## Check a certificate

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

Or straight from a server:

```
openssl s_client -connect host.example.com:443 -servername host.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -ext extendedKeyUsage
```

`TLS Web Server Authentication` alone means the certificate can't be used
as a client certificate. `TLS Web Client Authentication` in the list means
it still can, until it's renewed.

## Fixes

1. **Use a private CA for client certificates.** For connections between
   your own systems, or with partners who can trust your CA, issue client
   certificates from a private CA. This is what the CAs recommend.
2. **Buy a dedicated client authentication certificate.** Several CAs now
   sell certificates for client authentication from separate hierarchies.
   Check that the other side trusts that root.
3. **Update the product.** Vendors are releasing versions that no longer
   need client authentication on the public certificate; check their field
   notices before your next renewal.
4. **Find the renewal date.** You have until each certificate's next
   renewal. List them before then.

## Check your domain

The [certificate finder](/tools/find-ssl-certificates) lists every
certificate issued for your domain from public logs, with its issuer and
dates, so you can see which systems renew next. Nameward's monitoring
watches every hostname and alerts before each certificate expires.

## Sources

- [Chrome Root Program Policy](https://googlechrome.github.io/chromerootprogram/crp/policy)
- [Let's Encrypt: ending TLS client authentication](https://letsencrypt.org/2025/05/14/ending-tls-client-authentication)
- [Sectigo: client authentication EKU deprecation FAQ](https://www.sectigo.com/faq-client-authentication-eku-deprecation)
- [DigiCert: sunsetting client authentication EKU from public TLS certificates](https://knowledge.digicert.com/alerts/sunsetting-client-authentication-eku-from-digicert-public-tls-certificates)
- [Cisco: prepare Expressway for the client authentication change](https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway-series/225482-prepare-expressway-for-client.html)
- [Cisco: Expressway field notices](https://www.cisco.com/c/en/us/support/unified-communications/expressway-series/products-field-notices-list.html)

---
Source: https://nameward.app/guides/clientauth-eku-removed (updated 2026-10-30)