TLS certificates lose clientAuth on 15 March 2027.

What changes

A TLS certificate says what it may be used for in its extended key usage (EKU) extension. A server certificate asserts id-kp-serverAuth. Many CAs have long added id-kp-clientAuth as well, so the same certificate could also authenticate its owner as a client, for example a server that connects to another company's API with mutual TLS.

Chrome's root program wants hierarchies that serve only TLS server authentication. Its policy, version 1.8, sets the date for subscriber certificates:

“All corresponding subscriber certificates issued on or after March 15, 2027, MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth.”

— Chrome Root Program Policy 1.8, section 1.3.2

The same section already applies to intermediate CAs: those disclosed to CCADB from 15 June 2026 on may assert serverAuth only. Certificates issued before 15 March 2027 are not affected and stay valid until they expire. Under the CA/Browser Forum's schedule a certificate issued before that date lasts at most 200 days, so the last dual-EKU certificates expire by the end of September 2027.

• 2026-02-11 Let's Encrypt's default profile stops including clientAuth; a separate tlsclient profile keeps it for a while. — Let's Encrypt
• 2026-03-15 Maximum validity of a TLS certificate drops to 200 days. — CA/B Forum ballot SC-081v3
• 2026-06-15 Intermediate CAs disclosed to CCADB from this date on may assert serverAuth only. — Chrome Root Program Policy
• 2026-07-08 Let's Encrypt's tlsclient profile ends; it issues no more certificates with clientAuth. — Let's Encrypt
• 2027-03-15 New subscriber certificates may assert serverAuth only; maximum validity drops to 100 days. — Chrome Root Program Policy, SC-081v3

How far the CAs have come

The share of new publicly trusted TLS certificates that also assert clientAuth, week by week. In the week of 1 December 2025 it was 62.0%; in the week of 26 October 2026, 3.3%. Most of the drop is Let's Encrypt, the largest issuer, changing its default profile in February.

The share was lowest in the week of 27 July 2026, at 1.2%, and has grown since. So has the number behind it: 3,333,308 dual-EKU certificates that week, 4,658,681 in the week of 26 October 2026. Most of them now come from one DigiCert CA that issues one-week certificates for a single platform; the tables below show which.

Who still issues it

New TLS certificates of October 2026 by the organization that runs the issuing CA: how many asserted clientAuth as well, and what share of the organization's TLS certificates that was. Listed: every organization with at least 1,000 such certificates, and the largest issuers.

The same month by issuing CA, most dual-EKU certificates first. The last column is the share of those certificates valid for seven days or less; across the month it was 71.2%. A one-week certificate is renewed by automation, often for machines rather than websites.

Which domains they are for

The registrable domains behind the 19,713,824 dual-EKU certificates of October 2026, by the certificate's common name or first DNS name. sfdc.net alone accounts for 59.7% of them.

A certificate with clientAuth is not proof that anyone uses it as a client certificate: for many of them the EKU is just the CA's default. The numbers show where the change lands, not where it breaks something.

What breaks, and what to do

Websites are not affected: a browser only checks that a server certificate allows serverAuth. The change matters where a server certificate is also used as a client certificate, in mutual TLS: when your server connects to a partner's API, say, and presents its public certificate to prove who it is. The partner's server checks that certificate, and most TLS libraries reject a client certificate whose extended key usage lacks clientAuth. Such a setup keeps working until the certificate is renewed; the renewed one, without clientAuth, is refused and the connection fails. Typical cases are server-to-server mutual TLS between organizations, API gateways that authenticate partners by their public certificate, and services that authenticate each other with their server certificates.

Check what you have. Search your domain on ctlogs.dev: every certificate page lists its “Ext. key usage”. For a certificate on disk:

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

Find out where it is used as a client certificate. A certificate with clientAuth is harmless if nothing presents it as a client; look for outgoing connections that send it, and for partners that pinned it or its issuer.

Move client authentication to a dedicated CA. Use a private CA, or a CA's client-authentication hierarchy that is not part of the browser root programs. The partner that checks your client certificate has to trust that CA, so agree on the switch with them before your current certificate expires. Ask your CA when its TLS certificates drop clientAuth: some already have, others will by March 2027.

Sources

• Chrome Root Program Policy, version 1.8, section 1.3.2
• Ending TLS Client Authentication Certificate Support in 2026, Let's Encrypt, 14 May 2025, updated 16 March 2026
• SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods, CA/Browser Forum
• CCADB, the intermediate CAs counted here

Published 8 November 2026 by ctlogs.dev. Data as of 2026-11-08: every leaf certificate with serverAuth logged to the CT logs we ingest, issued by a CA disclosed in CCADB, counted once whether logged as a precertificate, a final certificate or both. Left out: 601,297 certificates of October 2026 from CAs not in CCADB, most of them from CT log test CAs, and from eMudhra's compromised CAs.