mTLS, done right, even as Chrome moves on.

For years, a single digital certificate could do double duty, proving a server’s identity to a visitor, and proving a client’s identity right back. That two-way handshake is the heart of mutual TLS (mTLS), the quiet workhorse behind secure APIs, connected devices, and zero-trust networks. It’s how a system knows that the thing on the other end of the connection is exactly who it claims to be.

Now the ground is shifting. Chrome has begun removing support for the client authentication capability inside the public web trust ecosystem, and Mozilla is expected to follow. The browsers’ reasoning is sound: the certificates that secure public websites and the certificates that authenticate clients are increasingly seen as two different jobs that deserve two different homes.

That’s good hygiene for the web. But if your business depends on mTLS, it raises an uncomfortable question: do you have to give up trusted client authentication to keep your websites working in modern browsers?

With SSL.com, the answer is no.

Two roots, two jobs, zero compromise

Think of a root certificate as the ultimate source of trust, the anchor that browsers and operating systems agree to vouch for. SSL.com operates more than one, and that’s the key to this whole story.

• Our 2016 roots are general-purpose. They were built to support a wide range of uses, including the client authentication that mTLS relies on.
• Our 2022 roots are purpose-built for TLS — dedicated solely to securing websites, exactly the way browsers now prefer.

When Chrome moved to retire client authentication, SSL.com made a deliberate choice rather than waiting to be told what to do: we asked Chrome to remove our general-purpose 2016 roots from its store. It may sound counterintuitive to volunteer a root for removal, but it’s precisely what keeps everything clean.

Removing the general-purpose root from browsers is what lets it keep doing the job browsers no longer want to do.

Here’s why it works. Our 2022 TLS roots are in Chrome’s trust store, so any website certificate that chains to them is fully trusted by Chrome today. And those 2022 roots are cross-signed by the older 2016 roots — a kind of trusted introduction, where the established root vouches for the newer one. That cross-signature gives your website certificates broad, durable compatibility across the long tail of older devices and systems that haven’t yet added the 2022 roots on their own.

Meanwhile, the 2016 general-purpose roots, now outside the browser store, are free to keep issuing mTLS certificates that carry both clientAuth and serverAuth, the two capabilities a mutual handshake needs. They never had to be browser-trusted to do that job. The browsers are out of the picture for mTLS anyway; what matters is that your systems trust the issuing root, and they will.

Why it matters now

Most certificate providers will eventually force a clean split, leaving customers to scramble for a separate source of client-authentication certificates, or to re-architect deployments under deadline pressure. SSL.com saw the change coming and engineered around it ahead of time, so the transition happens on our side, not yours.

• No re-architecting. Your existing mTLS patterns keep working with certificates issued the way they always have been.
• No browser breakage. Website certificates chain to roots Chrome already trusts, with cross-signed reach into older environments.
• One trusted partner. Server identity and client identity, both sourced from a CA with a long public audit history and roots embedded across the ecosystem.

This is the advantage of working with a Certificate Authority that treats root strategy as a product, not an afterthought. The browser landscape will keep evolving and the value of a provider that anticipates those moves only grows.

Keep both halves of trust intact.

Talk to SSL.com about mTLS certificates with clientAuth and serverAuth, and TLS certificates trusted in every modern browser, from a single CA built for what’s next.