If you're reading this, you're probably using digital certificates for client authentication or mutual TLS.
This is fine and good, as long as you are issuing certificates yourself from a 'private' CA or PKI you fully control.
You may have, or be looking for, certificates for client authentication or mTLS that are issued from a widely-trusted or 'public' CA.
DON'T.
YOU ARE NOT AUTHENTICATING ANYTHING. USING PUBLICLY-TRUSTED OR X9 PKI CERTIFICATES FOR CLIENT-AUTHENTICATION IS NOT AUTHENTICATION.
This is bad, unsafe, and thankfully - is being stopped. This page will help explain why that is, and what your options are.
Background
For a long time, public CAs issued server certificates for TLS (often still called 'SSL certificates') that included two EKUs.
From early 2027, Google are requiring that TLS server certificates issued from roots in their program (essentially any public CA that cares about being trusted by a browser and device that more than 60% of the world uses) be 'single purpose' - and do not contain the clientAuth EKU.
After mid-March 2027, it will no longer be possible to get a certificate that has both serverAuth and clientAuth EKUs and is publicly-trusted.
Client authentication with certificates
Using certificates for authenticating is great. It works in many enterprises, big and small, from Private CAs (a certificate authority that is only trusted within that enterprise - the opposite of a public CA that is trusted everywhere) where the enterprise controls issuance. They get to say who gets a certificate, how they get a certificate, what that certificate contains. From that, it's pretty easy to actually authenticate the holder of that certificate - safe in the knowledge that you issued it to the right user and that you alone could issue them that certificate.
Billions of certificates are used daily in this way to authenticate users, devices, servers-to-other-servers - all over the world, in enterprises of every size. Private CAs are great, and so is client certificate authentication.
Using a public CA for client authentication is great - if you're lazy. It removes the task of having to make people trust your private CA! Excellent!
If you're running a website, that would be great.
For client authentication, having it 'easy' is actually very, very bad.
Why is client authentication with publicly-trusted certificates bad?
You don't control how the certificate is issued!
Public CAs are governed by various rules - some from the CABF and some from the trust-store operators.
Those rules change. They determine what you can put into a certificate (no internal identifiers! no usernames!) and how long certificates are issued for, how they are validated and what CAs and roots they are issued from.
You, as a user, don't get a say.
Changes in recent years - and the future - are moving certificate lifetimes to 47 days or less. Issuing CAs are rotating annually at least. Roots every 5 years. Those are great things for security, but not ideal for client authentication...and you don't get to argue.
New changes come fast, too - often faster than many enterprises can cope with change.
You don't control who they are issued to!
Client authentication or mTLS only verifies a certificate is issued from a CA or set of CAs. Unless your application is doing additional checking (almost all do not, plus it's also very hard to check information that you did not verify and that you do not control the content or format of - or have the ability to check in real-time) then all you are doing is 'authenticating' that someone can get a certificate.
That might need a few dollars and a company registration, or it might require a 2-minute Google search.
Do you think you're authenticating more than someone's ability to use a browser and have a few dollars? You aren't. Again, say it with me this time:
ALL THAT YOU ARE AUTHENTICATING BY REQUIRING PUBLICLY-TRUSTED OR X9 CERTIFICATE FOR CLIENT AUTHENTICATION IS THAT SOMEONE CAN USE A COMPUTER
That's it. That's all. In case you are wondering:
No, you're not authenticating your users (you're just confirming they have enough internet to get a certificate)
No, you're not confirming they're a real 'valid' organization (CAs try and do that, but it's flawed. You don't ever check it, and you can't verify it in real time later anyway)
No, you're not confirming they're in control of a domain name (CAs DO verify this, once. Browsers check it every connection. You don't. And you couldn't, because the certificate being used isn't being used for a server!)
No, the public CA isn't accepting any liability for the certificate or your user (Warranties don't mean anything, you'd never be able to claim, and they won't count for non-TLS use)
If you are trusting even a specific subset of issuing CAs from a number of public CAs (say, OV and EV) - you're still opening the door to anyone who can get those certificates. Could be they have to spend $500. Could be they can get one for free, or via a reseller-of-a-reseller-of-a-reseller. You aren't authenticating anyone.
If you are trusting even a specific subset of issuing CAs from a number of public CAs (say, OV and EV) - you're still opening the door to anyone who can get those certificates. Could be they have to spend $500. Could be they can get one for free, or via a reseller-of-a-reseller-of-a-reseller. You aren't authenticating anyone.
What can I do instead?
There's a few options, depending on why you think you need a publicly-trusted client-certificate:
A third-party like my bank is forcing me to so that I can make API calls to them.
They're dumb, but understandably hard to convince them otherwise.
It's security theatre, and only in place to make their lives easier - what they should be doing is issuing you a certificate from their private CA (which they can pack with any information they wish!) and have you authenticate with that.
Hopefully when we get to early 2027 and none of their big customers that give them money can meet their requirements, they may see sense. Or they'll make a bigger mistake and look at X9 PKI.
Send them a link to this website?
My software vendor requires the certificate.
Ahh, Cisco Expressway. Go to the vendor, tell them you need an update that removes this requirement.
They should already be either planning or have already released one, if they're even halfway competent.
Install it. Update. Do it before the end of 2026. Excuses about costs, update cycles, testing - they won't help you when you're begging your CA for an exception they can't give in 2027.
I'm using publicly-trusted certificates to authenticate my users, or my customers, or do mTLS - either within my own infrastructure or with third-parties.
Move to a private CA.
Yes, it might be a challenge, but you have no choice.
You also aren't authenticating what you think you are, as explained on the rest of this website.
FAQs
I have lots of customers authenticating to me - I can't trust all their private CAs!
I think you've misunderstood what you're doing.
These customers are authenticating to YOU. YOU need to be issuing them with a credential (the certificate!) that they then authenticate to your systems with.
You don't need to trust other private CAs, just yours. You just have to actually get a private CA and issue certificates to your customers or users for them to authenticate back to you.
Imagine you outsourced creation of usernames: How would you know who your customers are? Would you trust them? Would they be in the right format? Who knows!
(Yes, there are systems where you might - things like OAuth - which are actually great alternatives to mTLS and client authentication and they're useful and viable!)
What if I can get my CA to just keep including the clientAuth EKU, or they say they'll keep doing it - or they have an older root they can use?
If you 'convince' your public CA to keep including the EKU - they won't be a public CA much longer. At least Google/Chrome will remove their roots and distrust anything they've issued from them.
Older roots...won't work in newer software/platforms/trust-stores - so why would that help, versus the control of a private CA?
Finally, if any root is still trusted in places, they'll need to adhere to the CABF BRs. That means: going towards short-lifetime certificates. Issuing CA rotation.
How can I setup a private CA?
There's lots of software out there, free and paid - but there's also lots of companies (including actual, audited public CAs - so you don't have to trust some rando company who claims to be secure!) who will run a PKI-as-a-Service for you. You might not even need that many certificates!
What about S/MIME certificates?
Yes, publicly-trusted S/MIME certificates still can contain the clientAuth EKU. However, that's not likely to be around forever, so don't rely on it. Many of the drawbacks mentioned here still apply - you aren't in control of how they're issued, who they're issued to, and when rules regarding their issuance might change.
Read this page again, use a private CA.
My CA is offering me a publicly-trusted client cert!
No, they're not. They're either using a root that's going to be removed from trust-stores soon (so it won't be publicly-trusted anymore!) or they've created specific client-authentication roots (for which there are no guidelines, so they won't be accepted into trust-stores).
Either way, you're not getting what you think you're getting, so I'd send them a link to this website while you ask for a refund.
What about X9 PKI?
X9 PKI is a group of financial institutions who got together and started a PKI ecosystem - fully admitting they aren't capable of dealing with positive security changes.
It's a 'shared' private CA, shared between the group - so it has all the drawbacks of a private CA (it's not widely trusted, not well-regulated) but none of the benefits (you're not in control of issuance, you don't control policy for issuance).
Security is somewhat laughable, too - rolling back progress by re-introducing 3-year certificates, banning wildcards, not requiring root and CA rotations...because they're all 'too hard to deal with'.
Single-sourcing on a single CA vendor. Lock-in and price hikes.
X9 PKI is just public admission that these banks and financial institurions don't take security seriously, so you shouldn't take their 'solution' seriously.
X9 PKI absolutely IS NOT a drop-in replacement for the deprecation of public client authentication. It may be useful for some of the banks and FIs to interoperate on non-public infrastructure, but beyond that, no-one should need it.
Unless you're a bank and you want your ATMs to talk to another bank's ATMs and you don't have the smarts to run your own private CA - steer clear of X9 PKI.
Some less-frequently-asked-questions and more whinging
But I ask my users to login and give me their certificate first, then I check it later!
Great. Use a Private CA for that, why not? You could even give them a certificate after they login - ask for a CSR and sign it! If you're actually verfying a certificate that has already been presented to you, then there's no reason at all to require a public CA issue it (aside from, of course, your laziness and not wanting to run a private CA!).
Google are wrong and bad for this decision!
Google are a lot of things, many of them bad - but this was clear technical decision, eliminating an insecure process and making everyone (including you) safer.
But this has always just worked!
Sure, and we used to live in caves, and movies came on actual physical discs, and we'd talk to people on the telephone instead of messaging them. It's called progress.
It's hard to manage a private CA, it was easy with a public CA!
That seems more like commentary on your ability than anything else.
Not everything is a browser!
Then it doesn't need a publicly-trusted certificate. Look, years ago, a public cert would be usable in many places for many things - but we grew up and got smarter.
The root programs who actually care, maintain these trust stores for their users - Google mostly care about browser and mobile device users, but Apple and Microsoft run OS-level trust stores, and they don't make special place for 'trusted' client certificates, because they know they don't work.