Ending TLS Client Authentication Certificate Support in 2026 (opens in new tab)

(letsencrypt.org)

4 pointsDunedan1y ago4 comments

4 comments

3 comments · 1 top-level

raxxorraxor1y ago· 2 in thread

> Google Chrome’s root program requirements, which impose a June 2026 deadline to split TLS Client and Server Authentication into separate PKIs

Can someone explain the reason for these changes? Personally I am a fan of clients not doing any form of authentication and I immediately think of something unconstructive like web integrity.

evanjrowley1y ago

Client authentication certificates are good for Mutual TLS (mTLS): https://en.m.wikipedia.org/wiki/Mutual_authentication

I think mTLS is great, but I wonder about the rationale for this change... If my front-end services are using a certificate to serve client requests, why shouldn't that same certificate also be used to authenticate them to backend services? Sure, a private CA seems like a reasonable thing to use here, but what makes PKI certs unreasonable for client authentication? Is it because we want to prevent client computer names from showing up in certificate transparency logs?

raxxorraxor1y ago

I miswrote my comment, I mean that I am skeptical of client auth, otherwise auth is of course sensible. But I think you understood that and client auth surely can make sense.

I assume this is for x509 certs specifically? I usually use simple ssh keys to identify users and servers towards each other, never really thought about entire certificate chains.

I would assume the number of devices potentially needing certificates is probably too much for PKI, but it would still be nice to know their reasoning.

1 more reply

j / k navigate · click thread line to collapse