Google has recently imposed a rule that CA roots trusted by Chrome must be used solely for the core server-authentication use case, and can't also be used for other stuff. They laid out the rationale here: https://googlechrome.github.io/chromerootprogram/moving-forw...

It's a little vague, but my understanding reading between the lines is that sometimes, when attempts were made to push through security-enhancing changes to the Web PKI, CAs would push back on the grounds that there'd be collateral damage to non-Web-PKI use cases with different cost-benefit profiles on security vs. availability, and the browser vendors want that to stop happening.

Let's Encrypt could of course continue offering client certificates if they wanted to, but they'd need to set up a separate root for those certificates to chain up to, and they don't think there's enough demand for that to be worth it.

Not precisely an answer, but there's some related discussion here:

https://cabforum.org/2025/06/11/minutes-of-the-f2f-65-meetin...

The real takeaway is that there's never been a lot of real thought put into supporting client authentication - e.g. there's no root CA program for client certificates. To use a term from that discussion, it's usually just "piggybacked" on server authentication.

No, it feels like the standard 'group/engineer/PM' didn't think anyone did anything different from their own implementation.

Lets Encrypt is just used for like, webservers right, why do this other stuff webservers never use.

Which does appear to be the thinking, though they blame Google, which also seems to have taken the 'webservers in general don't do this, it's not important' - https://letsencrypt.org/2025/05/14/ending-tls-client-authent...

Google forced separate client and server PKIs.[1]

[1] https://letsencrypt.org/2025/05/14/ending-tls-client-authent...