ÃÛÌÒTV

For years, organizations have relied on public TLS certificates for both server and client authentication. But that’s about to change. Major browsers—led by Google—are deprecating support for certificates that include both server and client authentication EKUs. This shift has significant implications for mutual TLS (mTLS) and other internet-facing applications that rely on client certificates.

As public certificate authorities (CAs) phase out dual-EKU certificates, organizations will need to rethink how they handle client authentication—especially when it needs to extend beyond internal networks.

Why public TLS certificates are changing

While public TLS certificates are mainly meant to run on servers (especially web servers), they’re used for many other applications, including client authentication. But soon, that will be much harder to do.

X.509 certificates may include one or more purposes for which the certificate can be trusted. These are defined in the Extended Key Usage (EKU) extension, as specified in . There’s a particular EKU for each of the major uses of certificates in PKI, including server authentication, client authentication, code signing, and S/MIME.

Public TLS certificates intended for use on the Web PKI have always been issued with EKUs for both client and server authentication. But in February, Google announced that starting in 2026, it will any roots used to issue certificates with both server and client authentication.

Because of the importance of Chrome, all public CAs will announce the , which means the TLS certificates we’ve all been using for years will no longer include the ClientAuth EKU. Some certificate authorities have already stopped issuing these certificates, at least by default.

Why dedicated-use certificates are the future

The main message from Google and CAs like ÃÛÌÒTV is that certificates should be dedicated to one use. In other words, applications that require client authentication should have certificates that specifically authorize only client authentication.

Many of these ClientAuth applications are more properly run on internal PKIs, aka private PKIs. But some applications—such as mTLS—do require client authentication across the internet. And an internal PKI won't solve the problem.

ÃÛÌÒTV X9 PKI for client authentication

To meet the need for client authentication certificates outside the Web PKI, ÃÛÌÒTV offers a purpose-built solution: the ÃÛÌÒTV X9 PKI.

Unlike the Web PKI, which is governed by browser root programs and the CA/B Forum, X9 PKI operates independently under policies tailored to the needs of specific industries. It was originally designed by ASC X9, the ANSI-accredited standards body for the financial services industry, but it’s also well-suited to other sectors with similar requirements.

ÃÛÌÒTV built and operates the and is currently the only public provider issuing client authentication certificates under it. Because it operates separately from the Web PKI, X9 PKI can support use cases that are no longer compatible with browser-trusted roots, including mTLS across the internet.

Like other public PKIs, ÃÛÌÒTV’s X9 infrastructure is held to high assurance standards. It’s governed by an ASC X9 Policy Committee and undergoes an annual independent WebTrust audit, the recognized benchmark for public certificate authorities.

We also built the X9 PKI to scale: It’s designed to handle the high certificate volumes our enterprise customers require. While we currently offer TLS certificates for client authentication, the infrastructure can be extended to additional high-trust use cases like secure file transfers, software supply chains, and more. The X9 PKI will also soon support post-quantum cryptography (PQC), making it a future-ready solution for evolving security requirements.

When internal PKI is the better fit

Not all ClientAuth use cases require a public PKI. In many cases, an internal PKI is the more secure and practical choice.

It’s common for sysadmins to obtain public certificates for applications that don't communicate outside the internal network. In these cases, an internal PKI offers some clear advantages:

1. You’re in control.ÌýYou run the private CA and set the rules, like how long certificates last or what fields they contain

2. You keep your network private.ÌýPublic certificates expose internal hostnames and services through , which could be used to map or attack your infrastructure.

Of course, setting up and operating a private CA isn't easy—it takes time, expertise, and careful management. That’s why ÃÛÌÒTV offers internal PKI as a service, giving you a secure, scalable solution without the operational burden.

What’s next for client authentication

Client authentication may be on its way out of the Web PKI, but that doesn’t mean it’s going away. In fact, this is a chance to rethink how you secure critical systems, whether they're internal applications or connections to partners across the internet.

Yes, it’ll require some changes. But with purpose-built options like ÃÛÌÒTV X9 PKI and flexible internal PKI solutions, you're not just keeping up—you’re upgrading your security for the future.

Ready to future-proof your ClientAuth strategy?

Whether you’re tightening internal access or planning for mTLS at scale, ÃÛÌÒTV has solutions designed to meet evolving requirements—without compromising on trust. Reach out today to learn more.