FAQ: Removal of Client Authentication from public TLS certificates

What has changed?

Publicly trusted TLS certificates can no longer be used to authenticate a client (clientAuth). For most of TLS usage, this changes nothing at all. For anyone using public certificates for mutual TLS or similar, it needs attention before the next renewal.

Does this affect you?

No – if you use TLS certificates the ordinary way. Securing a website, an API endpoint, a mail server, or any service that clients connect to. Server authentication is entirely unaffected. Your certificates will be issued, renewed and trusted exactly as before. No action is required and you can stop reading here.

Yes – if a system of yours presents a public TLS certificate as its own credential when connecting out to something else. The common cases:

• Mutual TLS (mTLS) between servers, services or business partners
• VPN or API gateway client authentication
• Device or machine identity built on a public certificate
• File transfer or EDI integrations where the counterparty requires a client certificate

Why this change?

The Google Chrome Root Program now requires publicly trusted TLS hierarchies to be dedicated to server authentication only, reflecting a broader industry move toward single-purpose certificates and hierarchies. Certificates issued under them assert serverAuth; clientAuth is no longer available. Because Chrome represents the majority of browser traffic, every public CA treats this as binding, and most have moved well ahead of the formal deadlines.

For GlobalSign, and therefore for most of TRUSTZONE’s publicly trusted products, the practical cutover was July 27th, 2026, when TLS issuance moved to new dedicated roots. Certificates from these hierarchies contain serverAuth only.

This is a change at CA hierarchy level. It is not a per-order setting, and as such exceptions cannot be requested.

Why issues tend to surface without warning

Certificates issued before the cutover keep their clientAuth EKU and keep working until they expire. The problem appears at the next renewal or reissue – and the new certificate looks completely healthy. It is validly issued, correctly formatted, and works perfectly for server authentication. It simply no longer carries the client authentication purpose, so the client side of the handshake fails.

What to do about it

Client authentication hasn’t gone away – it has moved out of the public Web PKI. There are three routes to re-establishing it:

1. Private-trust certificates that retain clientAuth – Such as TRUSTZONE IntranetSSL
   Issued under GlobalSign’s non-public roots, so unaffected by public root program policy. They also permit internal server names and reserved IP addresses, offer validity of up to five years. This is usually the fastest route, provided the systems involved can be configured to trust the private root.
2. A publicly trusted client certificate – Such as TRUSTZONE Personal Sign
   Either as a simple standalone Personal Sign certificate or through our managed Enterprise PKI solution (ePKI).
3. A dedicated private PKI
   Self-operated or delivered as a managed service such as GlobalSign Atlas. Full control over certificate profiles, EKUs and lifecycle, and no future exposure to public root program changes. Higher initial setup effort, but the right answer at scale or where client certificates are issued continuously.

Timeline of key events

• February 2025: Chrome Root Program Policy v1.6 codifies the phase-out of dual-purpose (serverAuth and clientAuth) publicly trusted TLS certificates.
• April 2025: CA/Browser Forum mandates the phase-out of dual-purpose (serverAuth and clientAuth) publicly trusted TLS certificates.
• September 2025: Several major certificate authorities stop including the clientAuth EKU by default in newly issued certificates.
• October 2025: Additional certificate authorities cease default clientAuth issuance, with limited exception processes running into 2026.
• July 27th, 2026: GlobalSign migrates all TLS certificate issuance to the new dedicated root hierarchies. From this date, GlobalSign TLS certificates contain serverAuth only.
• March 15th, 2027: Final Chrome Root Program deadline: no newly issued publicly trusted leaf certificate may contain the clientAuth EKU under any circumstances.

Our recommendation

If your organisation uses public TLS certificates for any form of client authentication, we recommend reviewing the relevant systems now, ahead of the next renewal cycle. For guidance specific to your setup, please contact support@trustzone.com and we will do our best to help you.