All tools

Guides Certificates and domains

TLS client auth EKU removal: what breaks

Updated 8 min read

Many public TLS certificates used to say they were good for two jobs: proving a server’s identity, and proving a client’s. The second job is going away. Most websites won’t notice; anything that uses a public certificate to log in to another server will.

Since February 11, 2026, certificates from Let’s Encrypt’s default profile are valid only for TLS server authentication. They no longer carry the “TLS Client Authentication” extended key usage (EKU), and since July 8, 2026, when Let’s Encrypt retired the temporary tlsclient profile, it issues no certificates with it at all (Upcoming Features).

Other public certificate authorities are on the same path. Google’s Chrome Root Program policy requires the hierarchies it trusts to be dedicated to TLS server authentication, and says subscriber certificates issued on or after March 15, 2027 must assert only server authentication.

For a website, nothing changes: browsers never needed the second purpose. What breaks is any setup where a public certificate is presented as a client certificate, to prove who is connecting.

What the EKU is

A certificate’s Extended Key Usage extension lists what the certificate may be used for. RFC 5280, which defines the format, names the two that matter here:

  • id-kp-serverAuth (OID 1.3.6.1.5.5.7.3.1): TLS server authentication, the job of every website certificate.
  • id-kp-clientAuth (OID 1.3.6.1.5.5.7.3.2): TLS client authentication, used when the side that opens the connection proves its identity with a certificate too.

OpenSSL prints them as “TLS Web Server Authentication” and “TLS Web Client Authentication”. For years, Let’s Encrypt certificates carried both, as did those of many other CAs, although, in Let’s Encrypt’s words, client authentication “is not typically used on the web, and is not required on the certificates used on a website.”

Why it is going away

Let’s Encrypt says the change “is prompted by changes to Google Chrome’s root program requirements”, which set a June 2026 deadline to split client and server authentication into separate hierarchies.

The current Chrome Root Program policy (version 1.8, updated February 5, 2026) explains the reason in section 1.3.2: Chrome relies on its root store only for TLS server authentication, so every hierarchy in it should serve that purpose alone. The rules in that section:

  • From June 15, 2026, Chrome phases out hierarchies found in violation, 90 days after the violation is detected.
  • Intermediate CAs disclosed on or after June 15, 2026 may assert only id-kp-serverAuth.
  • Subscriber certificates issued on or after March 15, 2027 must include the EKU extension and assert only id-kp-serverAuth.

The earlier version 1.7 set June 15, 2026 for subscriber certificates too, which is the deadline Let’s Encrypt planned around. Let’s Encrypt noted “some timeline changes in the root program requirements” in March 2026, which let it keep the tlsclient profile until July 8.

Date What happened
May 14, 2025 Let’s Encrypt announces the change; its tlsserver profile already leaves client authentication out.
October 1, 2025 Let’s Encrypt opens the opt-in tlsclient profile for anyone who needs more time.
February 11, 2026 The default classic profile drops client authentication.
June 15, 2026 Chrome starts phasing out hierarchies that are not dedicated to server authentication.
July 8, 2026 Let’s Encrypt retires tlsclient: no more certificates with client authentication.
March 15, 2027 Chrome’s deadline for every public CA: subscriber certificates assert only server authentication.

What breaks

The certificate itself still works for TLS servers. The failure appears on the other side of a connection: a server that asks the connecting party for a certificate, checks its purpose, and finds no client authentication in it. OpenSSL, for one, refuses such a certificate for client use when asked to check it. Here is a current Let’s Encrypt certificate, saved as leaf.pem with the rest of the chain its server sends in chain.pem, checked for each purpose with OpenSSL 3.6.4 on October 20, 2026:

openssl verify -purpose sslserver -untrusted chain.pem leaf.pem
openssl verify -purpose sslclient -untrusted chain.pem leaf.pem
leaf.pem: OK
CN=community.letsencrypt.org
error 26 at 0 depth lookup: unsuitable certificate purpose
C=US, O=Let's Encrypt, CN=YR2
error 26 at 1 depth lookup: unsuitable certificate purpose
C=US, O=ISRG, CN=Root YR
error 26 at 2 depth lookup: unsuitable certificate purpose
error leaf.pem: verification failed

The setups that hit this are the ones that use a public server certificate to authenticate one machine to another:

  • XMPP server-to-server connections. When one XMPP server connects to another, the server that opens the connection is the TLS client. The Prosody team explains that some TLS libraries reject a certificate without the client purpose, which “has the potential to break server-to-server connection authentication in XMPP”. Prosody accepts the new certificates; ejabberd needs version 25.08 or later. Prosody lists Openfire as compatible and says other software hasn’t been tested.
  • Mutual TLS with public certificates. An API, a partner integration or an internal service that requires a client certificate and accepts ones from public CAs can reject a server-only certificate once the client renews into one, if its TLS library checks the purpose.

If you only run websites and APIs that clients reach over ordinary HTTPS, none of this applies to you.

Check a certificate’s EKU

On a certificate file, such as the one your client presents:

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

On a live server, read the certificate it sends:

echo | openssl s_client -connect letsencrypt.org:443 -servername letsencrypt.org 2>/dev/null \
  | openssl x509 -noout -ext extendedKeyUsage

A server-only certificate, as Let’s Encrypt issues today (output from October 20, 2026):

X509v3 Extended Key Usage:
    TLS Web Server Authentication

A certificate that can still be used as a client certificate lists both purposes:

X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication

openssl x509 -in cert.pem -noout -purpose gives the same answer as a yes-or-no list (SSL client : No). If a certificate your systems present as a client certificate shows only server authentication, the next renewal of anything that still expects both is where things will fail. Check the client side’s CA and renewal date: the SSL certificate checker shows both for any public hostname.

What to do instead

Use a private CA for client certificates. Let’s Encrypt’s own advice is that “many uses of client authentication are better served by a private certificate authority.” A certificate from a public CA only proves that someone controlled a domain name; a private CA lets you decide exactly who gets a client certificate, for how long, and with what name, and lets the server trust that CA alone for client authentication instead of every public root. Issue the client certificates from it, install them on the machines that connect, and point the server’s client-certificate trust at your CA.

Upgrade XMPP servers that reject server-only certificates. For ejabberd, that means 25.08 or later. The Prosody post describes a test: send an XMPP ping to le-tlsserver.badxmpp.eu, which uses a server-only certificate; a successful reply means your server accepts them.

Ask partners what they accept. If a partner’s API authenticates you by a certificate from a public CA, ask them to accept server-only certificates for that check, or to issue you a client certificate from their own CA.

Don’t look for a public CA that still includes it. Let’s Encrypt’s tlsclient profile is gone, and Chrome’s policy requires every CA in its root store to issue server-only certificates from March 15, 2027. Postponing the migration only moves the failure to a later renewal.

Common questions

My website uses Let’s Encrypt. Do I need to do anything?

No. Browsers and other HTTPS clients check for server authentication, which every Let’s Encrypt certificate still has. Let’s Encrypt says most users who secure websites “won’t be affected and won’t need to take any action.”

Are my existing certificates affected?

A certificate keeps the EKU it was issued with. Let’s Encrypt certificates last 90 days, so every one issued before February 11, 2026 from the default profile has expired by now, and the last tlsclient certificates, from July 8, 2026, expire by early October 2026.

Did Let’s Encrypt’s intermediates change too?

Let’s Encrypt said that once the change was complete, it would switch to new intermediate CAs that also leave out client authentication. On October 20, 2026, the sites we checked were served from intermediates named YE2, YR1 and YR2. If your client pins a specific intermediate, which it shouldn’t, check it. Our SSL certificate statistics count which intermediates the top sites’ certificates come from, and how many still carry client authentication.

Sources

All sources were checked on October 20, 2026.

Keep reading