Chrome stops trusting client authentication certificates: what changes on 15 March 2027

Updated on 11 Sep 2026

The Chrome Root Program is removing client authentication from publicly trusted TLS certificates. This is not a change of advice or a security notice: it is a date after which certain certificates stop being usable for what they are used for today.

If two of your systems identify each other with a public TLS certificate — an API gateway that requires a client certificate, an integration with a partner, a service-to-service call — this article is for you.

The dates

Date What happens
15 June 2026 Public subordinate CAs lose the client authentication extended key usage. Already happened.
30 November 2026 DTCC requires X9 mTLS in its test environment.
31 December 2026 The same DTCC requirement, in production.
15 March 2027 Public subscriber certificates lose client authentication.

The last one is the cut. From that day, a certificate issued by a publicly trusted CA can no longer be used to authenticate a client, and any handshake that depends on it fails.

What breaks, and what does not

Breaks: any mutual TLS where the certificate presented by the client comes from a public authority. The symptom is not a warning; it is a refused connection.

Does not break:

  • Server certificates. Your website is unaffected; the change is to the client authentication key usage, not the server one.
  • Private and internal CAs. If your own CA issues your client certificates, nothing changes for you.
  • Encryption. This is not about algorithms or strength: it is about what a certificate is permitted to be used for.

How to tell whether it affects you

The hard part of this migration is not the certificate: it is remembering where it is used. Three places to look:

  1. API gateways and load balancers. Look for the configuration that requires a client certificate — in nginx, ssl_verify_client on; with ssl_client_certificate; in Apache, SSLVerifyClient require with SSLCACertificateFile.
  2. Service-to-service calls and scheduled jobs. Integrations that run at four in the morning and that nobody looks at until they fail.
  3. What your partners require of you. If somebody asked you for a certificate so you could connect to their API, that is one.

Once you have a certificate in front of you, ask it what it is for:

openssl x509 -in certificate.pem -noout -ext extendedKeyUsage

If the answer includes TLS Web Client Authentication, that certificate does client authentication. Now look at who issued it:

openssl x509 -in certificate.pem -noout -issuer

If the issuer is a public authority — DigiCert, Sectigo, GlobalSign, Let's Encrypt — it is one of the ones that stop working. If it is a CA of your own, breathe.

The options

There are three roads, and it is worth choosing with your eyes open.

Build or keep an internal CA. It works, and for communication strictly inside your own organisation it is usually the right answer. The cost is not the software: it is operating it — rotating the root, distributing trust, answering the question of who audits it. And between separate organisations it forces a one-to-one agreement with every partner.

A managed PKI. You pay somebody to operate the above. It solves the operations, not the interoperability: it is still your root, and the partner at the other end has to accept it.

The X9 PKI. An infrastructure built for exactly this gap: operated by DigiCert, governed by a policy committee of the Accredited Standards Committee X9 — the financial industry's standards body — and audited every year under WebTrust, the same as a public CA. It sits deliberately outside the CA/Browser Forum and the browser root programs, so that a decision taken for the web cannot break machine-to-machine trust again.

The practical difference from an internal CA is the common root: two organisations that have never met can trust each other because they trust the same audited authority, with nothing negotiated between them.

How to migrate without dropping the service

The order matters more than the speed. Done this way, both certificates are valid throughout the change and there is no window of downtime.

  1. Inventory. List every point where a client certificate is presented, the name or IP it presents, and which authority issued it.

  2. Separate what breaks. Only the ones issued by a public CA. Internal ones are out of scope.

  3. Order the new certificate with the names or IP addresses each client presents and the client authentication key usage. X9 accepts both domain names and IP addresses, including addresses in private ranges.

  4. Install the new root at the server end, alongside the one already there. This is the step that prevents the outage: the server now accepts both.

    # nginx: one file with both roots concatenated
ssl_client_certificate /etc/ssl/certs/trusted-roots.pem;
ssl_verify_client on;

  5. Swap the client certificates, one at a time, checking each connection.

  6. Only then remove the old root from the trust store.

Skip step 4 and swap the certificates first, and the server refuses the new clients until somebody remembers the root — which is discovered in production.

Frequently asked

Does this affect my website? No. Your site's certificate does server authentication, and that is unchanged.

Will browsers trust the X9 root? No, and that is the point. An X9 certificate authenticates systems to each other; put it on a website and the browser refuses it. For a website you need an ordinary SSL.

Can I keep using my internal CA? Yes. If all the communication is inside your own organisation, that is a legitimate option and none of these dates affect you.

What if I do not make it by 15 March 2027? Connections that rely on a public certificate to authenticate clients begin to fail. They do not degrade: they stop connecting.

Where to go next

TiendaSSL sells the X9 client authentication certificate, with organisation validation and issuance in one to two business days. If you would rather not do the migration yourself, our installation service covers both ends of the connection.