· Lyas Spiehler · Blog  · 5 min read

Public CAs Are Ending TLS Client Authentication Support

Organizations need to migrate to private Certificate Authorities before May 2026 to prevent service disruptions. Discover how a private CA platform like PKIaaS.io can keep your systems secure, reliable, and future-proof.

Organizations need to migrate to private Certificate Authorities before May 2026 to prevent service disruptions. Discover how a private CA platform like PKIaaS.io can keep your systems secure, reliable, and future-proof.

Public Certificate Authorities are ending support for TLS client authentication due to new Chrome Root Program requirements that take effect by May 2026. Organizations that rely on public CA-issued certificates for mutual TLS, device authentication, API authentication, or machine identity must migrate to a private Certificate Authority to avoid future outages.

This article explains why public CAs are deprecating TLS client authentication, who is affected by the change, and why switching to a private CA using PKIaaS.io is the correct long-term solution.

Login to try PKIaaS.io now!


Overview of the Chrome Root Program Change

Google Chrome’s Root Program now requires that publicly trusted CA hierarchies be dedicated exclusively to server authentication. Under these new rules, public Certificate Authorities can no longer issue TLS certificates that include the client authentication Extended Key Usage.

client-authentication-extended-key-usage

Historically, many public TLS certificates supported both server authentication and client authentication. This is no longer allowed under updated browser trust requirements.

By May 2026, public CA-issued certificates that contain the clientAuth EKU will no longer be trusted by Chrome. As a result, major public CAs such as DigiCert, Sectigo, and Let’s Encrypt are already removing support for TLS client authentication from publicly trusted certificates.

This change is commonly referred to as the TLS client authentication deprecation or public CA client auth phase-out.


What Is TLS Client Authentication?

TLS client authentication, often implemented as mutual TLS or mTLS, allows both the client and the server to authenticate each other using X.509 certificates.

Common use cases include:

  • Mutual TLS between services
  • API authentication
  • Machine-to-machine authentication
  • Device identity for VPNs, Wi-Fi, and IoT
  • Zero trust network access
  • Workload and service identity

Many organizations historically used public CA certificates for these use cases. That approach will no longer work once Chrome root program enforcement begins.


Who Is Impacted by the Public CA Client Authentication Phase-Out?

If you use public TLS certificates only for HTTPS on public websites, this change does not affect you.

You are impacted if you rely on public CA-issued certificates for any of the following:

  • Mutual TLS authentication
  • Client certificates for APIs
  • Device authentication certificates
  • VPN or Wi-Fi authentication
  • Internal service identity
  • Machine or workload authentication

If your certificates include the id-kp-clientAuth Extended Key Usage and are issued by a publicly trusted CA, you must replace them before May 2026.


Why Public Certificate Authorities Are Ending Client Authentication

Public CAs exist to secure public-facing server identities on the internet. They are not designed to manage private authentication systems.

Allowing a globally trusted public CA to issue client authentication certificates introduces unnecessary risk and complexity. Browser vendors are tightening trust models to reduce the blast radius of certificate mis-issuance and to clearly separate public web trust from private authentication use cases.

The Chrome Root Program changes formalize this separation. Public CAs secure public servers. Private CAs secure private identities.


Why a Private Certificate Authority Is the Correct Solution

A private Certificate Authority is the only viable replacement for public CA-issued client authentication certificates.

Private CAs provide:

Full Control Over Certificate Policies

You define key usage, certificate lifetimes, issuance workflows, and authentication policies without external restrictions.

Continued Support for TLS Client Authentication

Private CAs are not subject to browser root program rules. You can issue client authentication certificates indefinitely for mTLS and device identity.

Automation and Scalability

Modern private PKI platforms support API-driven certificate issuance, renewal, and revocation, enabling full lifecycle automation.

Improved Security Posture

Private PKI centralizes identity management, improves auditability, and reduces reliance on externally governed trust models.

Switching to a private CA is not a workaround. It is the correct architectural approach for certificate-based authentication.


Why PKIaaS.io Is the Right Private CA Platform

PKIaaS.io is a PKI as a Service platform designed to make private Certificate Authorities easy to deploy, operate, and scale.

As organizations search for solutions to replace public CA client authentication, PKIaaS.io provides a purpose-built alternative.

Simple Private CA Deployment

PKIaaS.io eliminates the need to build and manage your own CA infrastructure while preserving full control over trust and policy.

Certificate Lifecycle Automation

Issuance and renewal are automated through support protocols like SCEP and ACME, reducing operational overhead.

Designed for mTLS and Client Authentication

PKIaaS.io fully supports client authentication use cases including:

  • Mutual TLS
  • API and service authentication
  • Device identity for VPNs, Wi-Fi, and IoT
  • Zero trust and workload authentication

Secure by Default

PKIaaS.io follows modern PKI best practices and supports secure deployments that meet enterprise and compliance requirements.

For organizations affected by the public CA client authentication deprecation, PKIaaS.io provides a future-proof private CA solution.


Migration Planning Before May 2026

Organizations should begin planning their transition now.

Recommended steps include:

  1. Inventory all certificates that use client authentication.
  2. Identify certificates issued by public CAs.
  3. Design a private CA hierarchy for client authentication.
  4. Automate certificate lifecycle management.
  5. Replace public CA client certificates with private CA-issued certificates.

Waiting until enforcement begins increases the risk of outages and authentication failures.


Final Thoughts

The deprecation of TLS client authentication by public Certificate Authorities is a fundamental shift in how trust is managed on the internet.

Public CAs secure public servers. Private CAs secure private identities.

For organizations that rely on certificate-based authentication, migrating to a private CA is no longer optional. It is required.

PKIaaS.io makes that transition straightforward, scalable, and secure, while preserving full support for TLS client authentication well beyond May 2026. Login to try PKIaaS.io now!

Back to Blog

Related Posts

View All Posts »