Public mTLS Certs End May 1: Your Migration Guide

Starting May 1 — now ten days away — Sectigo, DigiCert, and other major Certificate Authorities will stop accepting requests to include the Client Authentication extended key usage (clientAuth EKU) in newly issued public TLS server certificates. It is easy to dismiss this as a procedural detail. If your organization uses public TLS certificates for mutual TLS (mTLS) authentication between services, it is anything but.

The deadline follows the Chrome root program’s enforcement policy, which requires that no public end-entity certificate carry both serverAuth and clientAuth EKUs after June 15, 2026. The CAs are enforcing their own cutoff six weeks earlier — once May 1 passes, you cannot obtain a new public cert with client auth, even on request.

What Is the clientAuth EKU, and Who Is Affected

A certificate’s extended key usage field tells software what the certificate is permitted to do. serverAuth means the certificate can authenticate a TLS server to a connecting client. clientAuth means the reverse — the certificate holder can authenticate itself to a server. Public TLS certificates historically combined both.

Server-to-server mTLS setups — API gateways verifying upstream callers, microservices authenticating to each other, payment processors validating merchant connections — often relied on this dual-use pattern. It was convenient. A single public certificate could handle both the outbound HTTPS and the inbound identity check.

That convenience is ending. The CA/Browser Forum, driven by Google Chrome’s root program requirements, decided that public trust infrastructure should not be used for client-side authentication. The separation is a security principle: client authentication deserves its own certificate management, purpose-built, under tighter controls.

The Two Deadlines You Need to Know

May 1, 2026: Sectigo, DigiCert, and other major CAs stop issuing any public TLS certificates with the clientAuth EKU — including renewals and reissues. Existing certificates are not revoked.
June 15, 2026: Chrome begins rejecting new end-entity TLS certificates that include the clientAuth EKU. Certificates already issued before June 15 with clientAuth remain valid until they expire naturally — but any renewal after May 1 will be issued without it, making May 1 the practical deadline for obtaining these certs at all.

If your certificates do not expire until late 2026 or beyond, you have some runway on the existing certs. The catch is that when renewal time comes, the CA will no longer issue a replacement that includes clientAuth. If you have not migrated your mTLS setup by then, the next renewal cycle will silently break server-to-server authentication.

What to Do Before May 1

The recommended migration path is Private PKI — a Certificate Authority you operate or have managed for you that sits outside the public WebPKI. Private CAs can issue certificates with any EKU combination you need, are not subject to CA/Browser Forum public trust requirements, and give you direct control over issuance policies.

Audit your mTLS usage: Identify every service, API gateway, or application that currently presents a public TLS certificate for client authentication. The clientAuth EKU appears in the “Extended Key Usage” field of the certificate — check your certificate inventory now.
Establish a Private CA: DigiCert’s Private PKI service and Sectigo’s Private CA offering are direct options. HashiCorp Vault, AWS Private CA, and Microsoft ADCS are self-managed alternatives. Financial services organizations are increasingly moving toward the X9 PKI Industry Forum’s framework, which is designed to meet the specific regulatory requirements of that sector.
Reissue authentication certificates from your Private CA: Replace the public certificates used for client authentication with private ones. Your server-facing TLS certificates for HTTPS are not affected and do not need to change.
Update trust anchors in client systems: Systems that validate client certificates will need to trust the new Private CA root rather than DigiCert’s or Sectigo’s commercial roots. This is typically the most time-consuming part — it touches configuration files, trust stores, and sometimes appliances with limited update mechanisms.
Test end-to-end before cutting over: Run a full mTLS handshake test with the new private certificates in staging before switching production over. The connection failure mode when a client cert is untrusted is often opaque.

The Broader Shift

This is part of the same underlying trend driving shorter certificate lifespans. The industry is narrowing the purpose of each certificate type and tightening how long any given credential stays valid. Public TLS certificates are moving toward a single, well-defined role: server authentication in browser-facing HTTPS. Client authentication, code signing, document signing, and device identity are each moving toward their own certificate ecosystems, with their own issuance controls and audit requirements.

Mixing purposes in a single certificate has always been a design compromise. The current changes are correcting that compromise, but the migration work is real and takes time. Ten days is enough to start — but not to finish if you are starting from zero.

Stay Ahead of the Next Deadline

The May 1 mTLS cutoff is one of several certificate changes landing in 2026, with the 100-day validity reduction coming in March 2027 not far behind. To track which of your certificates are expiring — and avoid missed renewals as lifespans continue to compress — SSLcalendar.com provides expiration alerts tailored to your domains. For visibility into the full certificate landscape across your infrastructure, including identifying certificates that currently carry the clientAuth EKU, SSLboard.com provides comprehensive certificate surveying and TLS health monitoring that can surface these before they become incidents.

Ten days is enough time to act. Just barely.

Sources: Sunsetting the clientAuth EKU from DigiCert public TLS certificates — DigiCert Knowledge Base, Client Authentication EKU Deprecation FAQ — Sectigo, Chrome: New SSL Certificates Can’t Support Client Authentication Starting June 15, 2026 — The SSL Store, Sunsetting the ClientAuth EKU: What, Why, and How to Prepare for the Change — RSAC Conference 2026, How the ClientAuth Crackdown Is Pushing Finance Toward X9 PKI — DigiCert