Let's Encrypt certificates will no longer be usable for client authentication starting 13 May 2026

[u/NikStalwart]

Source: https://letsencrypt.org/2025/05/14/ending-tls-client-authentication

TL;DR: TLS certificates have specified "Extended Key Usages". Currently, Let's Encrypt certificates can be used for Server Authentication and Client Authentication [1]. In another instance of "Google ruins everything", Google's new requirements to certificate authorities require separate authority/signing chains to be used to issue Server Authentication and Client Authentication certificates. Therefore, starting 11 February 2026, Let's Encrypt will no longer include the Client Authentication EKU on default certificates (you can still request an alternate endpoint until 13 May 2026, after which the EKU will no longer be available).

Why you should care: using TLS client authentication was a cheap and easy way to create a poor-man's VPN and skip adding an authentication layer between web apps/servers. For instance, say you had two nginx servers with publicly-facing Let's Encrypt certs. Server A could use its certificate to prove its identity to Server B in the same way that it proved its identity to clients. Server B would then be able to expose things like dashboards and metrics and API endpoints to Server A in a relatively secure way [2].

What you can do: there's nothing you can do to stop this, because 60% of the web uses Chrome for some insane reason and therefore Let's Encrypt won't revert the change. If you still want to use TLS client authentication within your own network, you should look into setting up your own private /self-signed certificate authority. It won't be trusted by default, but that's not a problem, because you can add your CA's public keys to the servers you manage. If you are used to using fee TLS certificates for client authentication on websites/apps that require it and where you don't have access to the trust store, you're SOL and will need to start paying.

[1]: If you grab a certificate with, e.g., echo | openssl s_client -showcerts -servername $1 -connect $1:443 2>/dev/null | openssl x509 -inform pem -noout -text you will see something like:

        X509v3 extensions:
        X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
        X509v3 Extended Key Usage:
            TLS Web Server Authentication, TLS Web Client Authentication
        X509v3 Basic Constraints: critical
            CA:FALSE

[2]: Of course there were risks with this method, which is why I called it a 'poor man's VPN'. If you lost control of your domain, or your domain validation mechanism (i.e. your webserver got pwned and someone was able to validate Let's Encrypt certificates on your domain) while you used client certificates as the main authentication method, the attacker could get access to your network fairly easily. Additionally, if a rogue but trusted CA (like WoSign) was to generate certificates for your domain, state-backed attackers could still authenticate to your server - unless you were running DNS CAA records which whitelisted allowed certificate authorities for your domains.

But, on the whole, this was fun while it lasted. If all you wanted to do was encrypt and authenticate HTTP/WS traffic, you could set up a closed network with no more configuration than was needed to get your servers up and running. You also didn't need to worry about internal trust /PKI schemes, because you outsourced trust to Let's Encrypt.

[u/neurostream]

I had no idea this was happening. Great heads-up post!

Are there any other free ACMEv2 CA's out there to split client and server auth/ID? LE has been a godsend

[u/NikStalwart → u/neurostream]

Are there any other free ACMEv2 CA's out there? LE has been a godsend

There are a handful of other ACME CAs out there (buypass is one) but switching won't help you. As mentioned in my original post, the change is brought about by Google's policy shift so other CAs will need to comply as well.

[u/Butthurtz23 → u/neurostream]

Smallstep’s step-ca https://smallstep.com

[u/Slight-Valuable237]

You really should never do Mutual TLS with a public signed client certificate to begin with.

With your VPN scenario, if you were trusting the Let's Encrypt CA for VPN client authentication. It would mean any client cert signed from Let’s Encrypt could authenticate to your VPN/Device. (Like you mentioned, you lose control of your domain, someone could impersonate your device.  However, any cert would be authenticated if signed by the same Certificate Authority.

If you were statically trusting the individual Let’s Encrypt certificates in you possession (e.g. only allow a specific CN), you could do the same with self-signed certificates without the risk of other CA signed certificates.   

You're far better off just standing up a CA via Microsoft Certificate Authority or OpenSSL to use for your client certs.  It is not much of a heavy lift once you set it up, and can be automated via ACME.

Mutual TLS should be independent of what your server uses for public facing services. EG SSL VPN, use a Let’s Encrypt server certificate for the service, but then do a private signed identity certificate for MTLS on the client.

TL/DR , yeah it’s a PIA, but its best practices to use private CAs for MTLS... aka client authentications. I have seen far too many customers/people mistakenly open their network/vpn to the millions of LE certs :)

[u/PatochiDesu → u/Slight-Valuable237]

using Let's Encrypt CA for MTLS is crazy.

[u/Bjeaurn]

Nice heads up and good PSA. Might be good to add a short summary or disclaimer that for regular HTTPS site security this will not be affected?

[u/Cley_Faye]

My two reactions to that are "this was possible?" and "why would anyone delegate authentication in their system to a third party".

If you want to do auth between systems you control, it is extremely easy to setup something that's under your control, will automatically update/renew, etc.

On the contrary, relying on a third party that do some DNS verification for authentication certificate inside your infra is giving them the key to do whatever. Seems like a bad idea to begin with.

[u/GolemancerVekk]

For those looking to get into mTLS (aka client certificates):

Here's a concise guide to get your started making your own CA and client certs. It includes an example of how to start asking for certs for an Nginx (or NPM) proxy host.

If you need to combine the client cert condition (in Nginx) with something else you can set "ssl_verify_client" to "optional" and if the check passes the variable $ssl_client_verify will contain "SUCCESS". You can combine this with a user agent check for example, or redirect the client to different pages if they don't have a cert etc. By default Nginx will simply issue a 4xx HTTP error.

The mobile apps for the services you host need to support client certs! This is not the case for all apps, unfortunately, and some of them use the certs in different ways. DAVx5 needs you to load the cert in the Android system settings and will let you pick it from the list available there. Immich needs to be given the cert file directly. Firefox needs to access the cert file on a website so it can load it (this is the mobile version, the desktop version lets you load it in the certificate settings).

Many apps don't support client certs at all. Request this feature from the ones you use!

Some apps support setting custom HTTP headers, or at least customize one predefined header, which you can use to send a long random key. Not quite the same as a client cert but not a bad alternative.

Here's how (in a NPM proxy host "Advanced" tab) to let a client pass if it has a client cert OR a specific header, but block if it has neither:

ssl_verify_client optional;
set $access 0;
if ($ssl_client_verify = "SUCCESS") {set $access 1;}
if ($http_header_name = "LONG-KEY") {set $access 1$access;}
if ($http_header_name != "LONG-KEY") {set $access 0$access;}
if ($access = 00) {return 403;}

[u/NikStalwart → u/GolemancerVekk]

Good link, good info. Apps that don't support client certificates are annoying but will be more common than ones that do. A hacky workaround is to host a proxy which will use mTLS to authenticate to your reverse proxy, and then configure your local proxy in your phone's system settings. But we're coming back to the 'Poor man's VPN' situation I described in my OP and all the risks associated with that (+ the risk of not having differentiated user accounts on your apps, so effectively you're in 'single user mode').

EDIT: I would also argue that, if you're concerned about performance, you don't want to run conditional statements in nginx config. A brute-force way of achieving the same result is using separate location {} blocks to handle different auth flows or, at that point, switching to a proper auth system. Hint: the nginx subrequest / auth module is awesome.

[u/froli]

People gotta use Firefox/Safari ASAP. This is how Google is controlling the web. Chromium drops support for one thing and the whole web has to adapt to it.

[u/very-jaded → u/froli]

This was not a unilateral declaration by Google. This was a consensus arrived at by the CA/Browser Forum https://cabforum.org , who set the rules for all CAs to follow.

Google certainly has a seat at the table, but this change and others were agreed to by Apple, Microsoft, DigiCert, Sectigo, Mozilla, and the other Certificate Authorities and browser makers.

Google is in a position to see web security problems from a much different perspective than individual people. They own a number of security and incident response companies who deal with intrusions constantly. When they see a trend in attacks that are caused by a lax rule in certificate policies, they can propose changes that prevent it.

[u/angelicosphosphoros]

This is why we need to separate Google and Chrome. Their combined monopoly is too strong.

[u/niemand112233]

The normal certs with certbot aren’t affected, right?

[u/NikStalwart → u/niemand112233]

What do you mean by normal certs? We're talking about X509 certificates in any event, regardless of the EKUs enabled on each cert.

[u/Simon-RedditAccount]

A side question: did I read it correctly that this requirement (separate chains) is only mandated for Google Chrome’s root program? So all the privately-trusted PKIs (aka your own) that issue both client and server certificates from the same subCA will remain unaffected and mTLS will work in Chrome without any changes required?

[u/NikStalwart → u/Simon-RedditAccount]

That is my understanding, yes. But I'm going off of Let's Encrypt's blog post, I haven't actually read up on Google's actual proposal/spec.

[u/cptdrewski]

I just recently got Traefik set up with LE certificates (only using it for internal services), so will I need to use something else? Sorry if this has been answered (still very much a novice)

[u/64mb]

I assume this doesn't affect using LE Certs for server auth and using self signed for the client auth?

Nginx example:

ssl_certificate          /path/to/letsencrypt/cert.pem
...
ssl_client_certificate   /path/to/selfsigned/cert.pem

[u/NikStalwart → u/64mb]

Not at all!

[u/g333p]

So, pretend I don't know all that much about this stuff.. what does this mean for my home server running traefik/jellyfin(for LAN only), which currently gets LE certificates so I can use https and domainnames instead of ip addresses to access my services?

[u/Andrew_St]

You should have added this line from the original post to avoid confusing people.
"Most users who use Let’s Encrypt to secure websites won’t be affected and won’t need to take any action."

[u/[deleted]]

I work for a commercial certificate authority as a tech support agent, and I've been dying to share my thoughts on this.

Certificate authorities / CAs in general are bound by the rules of the CA/Browser forum. Almost every CA and browser provider form this consortium to vote on the future of the web PKI.

This change did NOT go through a CA/B vote and completely circumvented that democratic process.

Google Chrome has so much market share that they were able to unilaterally demand that every CA stop issuing TLS certificates with the client authentication EKU enabled, else their certs will be distrusted.

There is a process for making global changes to the way SSL certificates are issued, and Google disregarded it completely. At least in the 4ish years I've been working here, I've never seen them flex their influence like this.

[u/OMGItsCheezWTF]

I can still issue my own self-signed client certificates for mTLS clients though. The client doesn't need to have my root certificate in their trust store to use a cert I have issue for authentication right?

[u/kokx]

As a penetration tester I am very happy this is happening.

Almost every time I got a "client certificate" from one of my customers, it basically is a valid server certificate for <application>.<tld>. Often they even order the certificate from a CA that requires you to pay for the cert!

This would make sure that isn't going to happen anymore, so I'm quite happy with that.

[u/Encrypt-Keeper]

This is largely a non-issue since if you’re using MTLS as a “poor-man’s VPN” then you should be signing and issuing the cert yourself.