# Let's Encrypt certificates drop TLS client authentication

> Since 2026-02-11 Let's Encrypt's default classic profile omits the clientAuth EKU; the temporary tlsclient profile ended on 2026-07-08.

Source: https://ssl.sh/news/lets-encrypt-ends-tls-client-authentication/
Last updated: 2026-11-10

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](https://ssl.sh/glossary/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](https://ssl.sh/news/chrome-dedicated-tls-hierarchies/). 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](https://ssl.sh/glossary/mtls/). Let's Encrypt's new [Generation Y intermediates](https://ssl.sh/news/lets-encrypt-generation-y-hierarchy/) 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](https://ssl.sh/glossary/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](https://ssl.sh/errors/client-auth-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:

```bash
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](https://ssl.sh/glossary/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:

```bash
# 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:

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

The [mTLS guide](https://ssl.sh/learn/mtls/) walks through a full set-up, and the [certificate decoder](https://ssl.sh/tools/certificate-decoder/) shows the EKU of any certificate you paste in.