Overview
Digital certificates (x.509 certificates, often still called SSL certificates) come in many
different types.
This guide is focussed on a specific type of certificate meeting the following criteria:
- Publicly-trusted: Certificates which inherit trust from a root CA which is widely distributed
into web-browsers and operating systems.
This means certificates issued from trusted CAs - such as Let's Encrypt, Sectigo, DigiCert and others.
- Server certificates: Certificates which are used for TLS-capable servers. Web servers for
HTTPS being the main use case. Often still called 'SSL certificates'.
These certificates will contain the 'serverAuth' EKU.
These are not S/MIME, codesigning, PDF, document signing or other types of certificate.
For many years, these server certificates that used the serverAuth EKU also included the clientAuth EKU. This meant the same certificate could be usd to 'identify' a client, not just a TLS server. It became possible to use the single certificate for client and server authentication - often called 'mTLS' or 'mutual TLS' or 'server-to-server authentication'. A number of services, commonly APIs for financial institutions, began requiring customers use a server certificate to authenticate themselves in addition to their credentials. These services may not only require a publicly-trusted server certificate with clientAuth to work, but some require the certificate to be of a certain type ('OV' or 'EV') or from a specific issuing CA.
What is changing?
Google's Chrome Root Program have a set of policies and requirements that must be met in order for a CA to have their roots included in Google products. As this covers billions of users of Chrome, Android and other Google products, it means a publicly-trusted CA must adhere to these rules. Google's CRP has stated that from [June 2026] all certificates with the serverAuth EKU cannot also include the clientAuth EKU. Doing so will cause Google to functionally remove the roots from which those certificates are issued. This means from [June 2026], server certificates that are publicly-trusted will no longer be usable for client authentication, mTLS or server-server authentication. Any user or service requiring this will need to move to alternative solutions before certificates issued prior will expire.
Why is this happening?
Google, along with others in the public CA industry (the 'webPKI' and the CA Browser Forum) are moving towards having 'single purpose hierarchies'. That is, having a certificate issued from a CA and root that is dedicated to a single use-case - server authentication, S/MIME secured email, codesigning, document signing or other single purpose. Certificates should serve a single purpose, preventing potential abuse, reducing risk for the billions of relying parties who trust certificates every day.
Why is this good?
Using publicly-trusted certificates for authentication is BAD. It is a security risk. It does not provide any meaningful authentication. There is a single reason that publicly-trusted server certificates were used for mTLS or client authentication: It was easy. It just worked. Instead of evaluating what security was provided, or setting up a dedicated private PKI, it was far easier to just use an easily-available product, or to tell a user to go and obtain a certificate from a third-party CA like Let's Encrypt, Sectigo or DigiCert. Little consideration was given to what was actually authenticated, how safe that was, and if the solution would work into the future. However, there are many reasons why publicly-trusted certificates are bad for client authentication:
- Client authentication with publicly-trusted certificates don't actually authenticate
anything.
Any service requiring a client certificate issued by a third-party will not actually authenticate anything. When a server certificate is used on a HTTPS website, the browser will verify the fully-qualified-domain-names in the certificate, verify the certificate is valid, verify the certificate is not revoked. This is how billions of HTTPS transactions happen every second around the globe. When a server certificate is used by an enterprise or a service to require a user to authenticate as a client - no validation is done. The FQDN is not (and mostly cannot) be checked. The Subject information, if using an OV or EV certificate, is not checked. The only thing that is being authenticated is that a user has an internet connection and perhaps a few dollars to purchase a certificate. That is the barrier to entry. That is the level of 'authentication' happening - which is, effectively, none.
Using publicly-trusted server certificates for client authentication is not authenticating anything.
- You are not in control of the issuance of the certificates.
Delegating creation and validation of authentication tokens (certificates) to a third-party is fraught with risk anyway, but delegating to a third-party who you have no control over, and is subject to external regulation is even more dangerous. Publicly-trusted CAs must Many enterprises worldwide use certificates to authenticate their devices to networks and VPNs. All of these are done with Private PKI - the enterprise can verify who or what they are giving a certificate to, entirely within the control of their organization. This is a totally standard practice, and would not be done with publicly-trusted certificates.
- Changes to server certificates mean using them for authentication is going to get harder anyway.
Server certificates are already being reduced in lifetime from around 1 year, down to 47 days in early 2029. Issuing CAs will need to be changed every year by publicly-trusted CAs. They should ideally be randomised - so you cannot guarantee your users or customers can get a certificate from a specific CA. Publicly-trusted CAs will need to rotate their root certificates on at least a 5-year basis. The pace of change in the public-CA world from the root store operators and CA/B Forum is increasing. Changes can, and will, happen with short notice and would heavily impact use-cases that aren't using server certificates for TLS servers.
What are my alternatives?
There are 3 possible alternatives.
- Private PKI
A Private PKI is one dedicated to just your organisation/enterprise/group. You control the issuance of certificates to whoever you wish and however you wish. You control what those certificates look like, what they contain, how long they are valid for. Every aspect is within your control. No external organisation can make you change those certificates - Google, Apple, Microsoft, Mozilla, CA/B Forum - none of them have purview over your Private PKI. Private PKIs are used the world over by enterprises to use certificates to authenticate their devices to their networks, their wifi, their VPNs. It's a proven use-case where publicly-trusted certificates simply don't fit. The one aspect to consider is 'provisioning' - that is, how you get a certificate to your user. Simple web-based forms for them to enroll with a CSR is the easiest option, which you can do in a portal or control panel after the user has already logged in. Running a Private PKI does not need to be complicated. There are easy and free tools available, as well as fully-managed services - available from the publicly-trusted CAs you work with today. You do not need to use an existing Private PKI that you may already have. You can setup a new PKI, or a new issuing CA just for this client-authentication purpose.
- S/MIME certificates.
Most publicly-trusted CAs will also issue S/MIME certificates. These are a certificate type used to digitally sign and encrypt email. They are publicly-trusted. Currently, they can contain the clientAuth EKU. They will also contain a validated email address - something more likely practical for you to verify and bind to your users identity. However - these do have some of the same drawbacks as server certificates. You are not in control of how they are issued, or the regulations surrounding their issuance. It is possible, and even likely, that the clientAuth EKU will also be removed from S/MIME certificates in the future. It may be a temporary stop-gap solution until you migrate to a Private PKI.
- Not using certificates.
There are many different authentication methods available which are secure, scaleable and suited to many use-cases. It's entirely possible to replace the client-certificate authentication with something easier, safer, and with no reliance on third-parties.
FAQs
What if a third-party service I use requires it?
There are third-party services, often financial or telecoms, which still require publicly-trusted server certificates with clientAuth EKUs. The best thing to do is to educate them. Send them to this site, have them reach out to any CA you work with, and help them understand this requirement is coming, and whatever they think they are authenticating - they are not. They'll need to replace or change their system requirements otherwise they'll likely face some serious outages.
Can I just find a CA who'll give me what I want?
Perhaps. Any CA violating the Google policy will find themselves rapidly removed from the Google Chrome Root Program, effectively ending their ability to be a publicly-trusted CA. As we've seen with Symantec and Entrust before, that is an effective death penalty for a publicly-trusted CA.
How can I get and use a Private PKI?
Private PKI or Private CA solutions are much easier to setup than you may think. Most CAs offer Private PKI solutions, and most of the major cloud vendors also do.
What if I don't want to use my existing Private PKI?
You don't have to use your existing PKI for this. It may be better to establish a new Private PKI hierarchy, or a dedicated issuing CA from our existing Private PKI.
What about some CAs that offer clientAuth only certificates?
Publicly trusted clientAuth certificates are still a bad idea. The roots from which they are issued will not be widely-trusted as Google and likely other root-store operators will remove them. They still do not authenticate anything. They are at best a temporary, lazy solution. At worst they are dangerous and increase risk to your organisation.
What about S/MIME certificates?
S/MIME certificates can still be issued with the clientAuth EKU today - however, there are still the same drawbacks as with publicly-trusted server certificates, and the rules may change at any time in the future removing clientAuth from these cert types too.
What about x9 PKI?
x9 PKI is just a 'Private' PKI that's designed to be shared amongst participating entities. It has many of the same drawbacks as publicly-trusted CAs in that your organization has no control over the issuance of certificates or changes to standards. It's a simple swap from Google and the other root-store operators, for group of financial service providers. It currently only has a single CA issuing certificates, increasing risk tying to a single vendor. Many of the suggested reasons for x9 PKI's existence is that migration to better security standards were 'too hard'. Everything in the x9 PKI can be done with your own Private PKI, and give you more control and less reliance on third parties making changes that affect your infrastructure.
What if I can't use certificates anymore?
That may well be the correct answer. There are myriad secure, scaleable authentication systems available that would be suitable for your use-case, and almost certainly a better fit than client certificates. It is best not to assume that client certificate authentication is the 'right' solution.