For years, Client Authentication (mTLS) has been implemented using public SSL/TLS certificates issued by publicly trusted certification authorities. This model worked because server certificates could include both Server Authentication and Client Authentication (EKU), and browsers and operating systems accepted such a dual-use scenario.

This model is now coming to an end.

Under new root program rules, particularly those of the Chrome Root Program, public TLS is intended solely for server authentication, not client authentication. As a result, major public certificate authorities have begun phasing out Client Authentication support in public certificates.

For many organizations, this creates a real risk of silent mTLS failures during automated certificate renewals.

What exactly is changing?

Change timelines among major providers.

DigiCert

• Client Authentication EKU is no longer added by default to new public certificates.
• The option to enable it will be completely removed on May 1, 2026.
• After this date, DigiCert Public TLS certificates will support Server Authentication only.

Sectigo

• Sectigo is sunsetting Client Authentication in public TLS certificates.
• Final cutoff date: May 15, 2026.
• After this date, reissuance or new orders will no longer be able to include Client EKU.

These changes are not isolated decisions by individual CAs, but a direct consequence of root program policies, including browser requirements.

Why is this an operational issue and not just a formal one?

In many environments, mTLS based on public certificates has been operating for years without being redesigned. Typical examples include:

• B2B and site-to-site VPNs.
• API gateways and partner integrations.
• SIP, VoIP, and Unified Communications.
• Edge security, reverse proxies, and ingress controllers.
• Legacy M2M integrations where the certificate represents identity.

In such scenarios, renewing a certificate without Client EKU results in:

• inability to establish connections,
• client-side authentication errors,
• hard-to-diagnose incidents after the old certificate expires.

Importantly, the change may occur silently if the renewal process is fully automated.

Short-term mitigation options (until 2026).

Reissuance before the cutoff date.

If you currently rely on public TLS for Client Authentication, your time window is limited.

DigiCert

• During ordering or reissuance, Client Authentication EKU can still be explicitly enabled.
• The certificate can retain functionality for up to one year after issuance.
• This is a temporary workaround, not a strategic solution.

Sectigo

• Certificates issued by Sectigo include Client Authentication for orders placed since November 2025.
• If a certificate was issued without EKU, a reissuance before May 15, 2026 is required.

It must be clearly stated that this only postpones the problem, rather than solving it.

Long-term, future-proof solutions.

Cross-organization traffic: X9 PKI.

For B2B, financial, and regulated environments, the correct direction is PKI outside browser root programs.

DigiCert X9 PKI for TLS

• Based on the ASC X9 Certificate Policy rather than browser root policies.
• Supports both Server Authentication and Client Authentication.
• Designed for scenarios such as:
  • cross-organization communication,
  • mTLS,
  • critical system integrations.

Internal systems: Private CA / Managed PKI.

For internal and hybrid environments:

• private certification authorities,
• Managed Private CA (PKI as a Service),
• full control over EKUs, policies, and certificate lifecycles.

This is currently the recommended model for:

• Kubernetes,
• microservices,
• Zero Trust architectures,
• service-to-service authentication.

Visibility and automation: the key to security.

Regardless of the chosen model, certificate visibility is critical. Tools such as DigiCert Trust Lifecycle Manager enable organizations to:

• discover all certificates used for Client Authentication,
• identify dependencies,
• plan migration paths,
• automate renewals and key rotation.

A lack of certificate inventory is one of the most common sources of operational incidents today.

Recommended action plan (checklist).

1. Identify all locations where Client Authentication is used:
   • VPN, API, SIP, UC, reverse proxy, edge.
2. Secure short-term continuity:
   • reissue certificates before the cutoff dates.
3. Select a target model:
   • X9 PKI for cross-organization traffic.
   • Private CA for internal systems.
4. Update trust stores:
   • new root and intermediate CAs.
5. Enable discovery and automation:
   • monitoring, alerting, lifecycle management.

The removal of Client Authentication from public SSL/TLS certificates is not a temporary policy shift, but a permanent transformation of the Internet trust model. Organizations that continue to rely on public SSL for mTLS must make architectural decisions in 2026 to avoid outages and security incidents.

We recommend treating this moment as an opportunity to clean up PKI, improve visibility, and implement a modern trust model rather than applying another temporary workaround.

If you need support with audits, migration, or selecting the right PKI model, our team remains at your disposal.