The End of Public TLS Certificates for mTLS: Choosing the Right PKI Hierarchy

Mutual TLS has become a quiet workhorse of modern architecture. Wherever two systems need to authenticate each other, rather than just encrypt a connection, mTLS is often the mechanism. A significant number of organisations have built that authentication on publicly trusted TLS certificates, partly out of convenience. That convenience is coming to an end, and the change has real architectural consequences.

Browsers, led by Google, are moving to remove trust for root certificates that issue certificates carrying both server and client authentication purposes. The effect is to end the use of public TLS certificates for mTLS. This article explains why that is happening and, more usefully, how to choose the right private or non-Web PKI hierarchy to replace it.

Why public certificates are being withdrawn from this role

Public TLS certificates exist to secure the public web. Over time, the certificate field that signals a certificate's intended purpose, the extended key usage, has often included both server and client authentication, which made it convenient to reuse a public certificate for mTLS. The Web PKI is now tightening its scope: roots that mix these purposes are being separated out, so that publicly trusted certificates do what they are meant to do and nothing else.

This is part of a broader hygiene effort in the public trust ecosystem. For organisations, the headline is simple: if your mTLS depends on publicly trusted certificates carrying client authentication, that arrangement is on a timeline to stop working.

The deeper point: mTLS was never really a Web PKI problem

It is worth stepping back. The public Web PKI is designed for a specific job: letting any browser in the world trust any public website without prior arrangement. Machine-to-machine authentication inside or between organisations is a different problem. The parties are known, the relationships are defined, and the trust does not need to be globally anchored. Using public certificates for mTLS was always a slightly awkward fit. The current change is, in effect, the ecosystem insisting that the right tool be used for the job.

Choosing the right replacement

There is no single correct answer; the right hierarchy depends on where the traffic flows and who needs to trust it. Two broad options cover most cases.

Internal or private CAs

Where mTLS happens within your own environment, between your services, devices or internal systems, a private certificate authority is usually the right home. You control the trust, you issue certificates scoped specifically to client or server roles, and you are insulated from public Web PKI policy changes. A well-designed private PKI also gives you the lifecycle control that machine identity at scale demands.

Separately audited non-Web PKI hierarchies

Where traffic crosses organisational boundaries or the public internet, but does not belong in the Web PKI, a dedicated, separately audited non-Web hierarchy can provide the assurance of a recognised trust framework without the constraints that apply to public TLS. This is increasingly how cross-organisation machine identity is being handled.

Getting the architecture right

The withdrawal of public certificates from mTLS is, in the end, an opportunity to put machine identity on a proper footing. The organisations that handle this well will be those that treat it as a design question rather than a scramble for replacement certificates.

• Map where mTLS is in use and which certificates currently support it.
• Separate server and client authentication needs explicitly, rather than relying on dual-purpose certificates.
• Decide, per flow, whether a private CA or a non-Web hierarchy is the right trust anchor.
• Build lifecycle management in from the start, because machine identity multiplies quickly.

This is core PKI design and build territory, and it connects directly to the role of PKI in zero-trust strategies, where strong machine identity is foundational. If you are unsure how your hierarchy should be structured, our PKI consultancy can help you design it deliberately.

‍