The End of clientAuth: Why mTLS With Public Certificates Is Running Out
The Chrome Root Program requires dedicated server hierarchies: new intermediate CAs since June 2026, and leaf certificates from 15 March 2027, may assert serverAuth only. Where mTLS with public certificates breaks, and why client identities belong in a PKI of your own.
For a long time, a publicly trusted TLS certificate could do two things at once: identify a server to browsers and identify a client to another server. The Extended Key Usage extension made this possible with the purposes serverAuth and clientAuth. That dual role is ending. The Chrome Root Program policy requires hierarchies dedicated exclusively to server authentication.
The key dates
Under version 1.8 of the Chrome Root Program Policy, two dates apply:
- Since 15 June 2026, intermediate CAs newly disclosed to the CCADB may assert only the serverAuth purpose.
- From 15 March 2027, the same applies to every leaf certificate issued.
Certificate authorities are moving earlier. DigiCert, for example, has issued public TLS certificates without clientAuth by default since 1 October 2025 and, according to its own announcement, will remove the option entirely on 1 March 2027. Anyone relying on the Chrome date may therefore meet the change at their next renewal.
Existing certificates remain valid until they expire. Because the maximum validity has been 200 days since 15 March 2026, however, the transition is short: a certificate issued with clientAuth on the last permitted day expires by the end of September 2027 at the latest. After that, no valid leaf certificate from a Chrome-trusted hierarchy carries this purpose.
Where it breaks
Browsers are barely affected, because they verify servers. The connections affected are those in which a system presents a public certificate as a client:
- Partner interfaces: B2B connections where both sides authenticate via mTLS and the client certificate comes from a public CA.
- Server-to-server traffic: services that use their own server certificate as a client identity towards other services.
- Devices and agents: endpoints that present publicly issued certificates to a central service.
The tricky part is timing. The failure does not appear on the key date but at the first renewal after it, often automated and often at night. The new certificate is valid, yet the TLS handshake fails because the other side requires the clientAuth purpose.
Client identities belong in a PKI of your own
Chrome is not abolishing mTLS. The policy simply separates purposes: public CAs identify servers to the general public, while client identities are issued within a trust relationship that the parties involved control themselves. From a security standpoint, that is cleaner anyway. Trusting a public CA as a client issuer potentially means accepting any certificate from that CA, not just your partner’s.
Four steps have proven useful for the transition. First, the inventory: which certificates carry clientAuth today, and which of them are actually used as clients? The certificate alone does not tell you; only matching it against the connections does. Second, a dedicated certificate authority for client purposes, kept separate from anything that identifies servers. Third, coordination with partners, since every counterparty has to install the new trust anchor, and that takes lead time. Fourth, automated issuance and renewal, so that your own PKI does not become a new manual burden.
NextPKI follows exactly this pattern: first make the inventory visible, then automate renewal, independent of the issuing CA. The decisive step, however, comes before any tool: finding the connections that silently depend on clientAuth today.
15 March 2027 is not the day mTLS breaks. It is the day from which any renewal can break it.