FAQ: Removal of Client Authentication (clientAuth) from publicly trusted TLS certificates

What is changing? Publicly trusted TLS certificates can no longer be used to authenticate a client. 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

What has changed?

The Google Chrome Root Program now requires publicly trusted TLS hierarchies to be dedicated to server authentication only. 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 27 July 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 it tends 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:

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 15th, 2025: Several major certificate authorities stop including the clientAuth EKU by default in newly issued certificates.
• October 1st, 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.