Let's Encrypt certificates drop TLS client authentication

Let's Encrypt certificates no longer work as TLS client certificates. On 11 February 2026 the default classic profile stopped including the clientAuth extended key usage, so new certificates are valid for server authentication only. A temporary tlsclient profile that kept clientAuth for late movers was discontinued on 8 July 2026.

What happened

Dropping clientAuth follows the industry move toward certificate hierarchies dedicated to server authentication, driven by the Chrome Root Program's policy. Let's Encrypt announced the plan on 14 May 2025. Until then its certificates listed two purposes in the EKU extension: TLS Web Server Authentication and TLS Web Client Authentication. The second allowed a server to present the same certificate as a client in mutual TLS. Let's Encrypt's new Generation Y intermediates carry no clientAuth either.

Timeline:

• 2025-05-14: change announced.
• 2025-10-01: tlsclient profile launched as a temporary option.
• 2026-02-11: classic profile stops including clientAuth.
• 2026-07-08: tlsclient profile discontinued.

Who is affected

Most websites are unaffected, because browsers only check for serverAuth. The change affects:

• server-to-server mTLS in which each side presents its public certificate as a client certificate, for example APIs that authenticate partners this way;
• mail relays and other servers that present their certificate when connecting outward, where the receiving side checks the client certificate's EKU;
• any software that validates a client certificate's purpose before accepting it.

The usual symptom is a failed handshake on the verifying side, often with an OpenSSL error such as unsupported certificate purpose. The clientAuth EKU removed page lists messages from other stacks.

What you should do

Move client authentication to a private CA. First check what a certificate is allowed to do:

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

A current Let's Encrypt certificate shows only TLS Web Server Authentication.

For client authentication, use a private CA that you control. You decide the lifetime and EKU, and the verifying server trusts only your CA, which is also safer than accepting any publicly trusted certificate:

# issue a client certificate from your own CA, clientAuth only
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 365 -out client.crt \
  -extfile <(printf "extendedKeyUsage=clientAuth\nbasicConstraints=CA:FALSE")

On nginx, point the verifying side at that CA:

ssl_client_certificate /etc/nginx/client-ca.crt;
ssl_verify_client on;

The mTLS guide walks through a full set-up, and the certificate decoder shows the EKU of any certificate you paste in.