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
- 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.
- 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.
- 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.
- Find the renewal date. You have until each certificate's next renewal. List them before then.
Check your domain
The certificate finder 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.