> 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.
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?
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.
I suppose they might want to stop issuing client auth certificates because it means anyone with a PKI-signed cert could potentially authenticate as a client to a server. With PKI being a series of trust relationships among CAs, there's effectively no control over what gets accepted vs. rejected. I suppose from that perspective only private CAs make sense.
If you want to try using a private CA for x509 certificates to do SSH client authentication, I know of a couple solutions that make it easy to do:
> 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.
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?
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.
I suppose they might want to stop issuing client auth certificates because it means anyone with a PKI-signed cert could potentially authenticate as a client to a server. With PKI being a series of trust relationships among CAs, there's effectively no control over what gets accepted vs. rejected. I suppose from that perspective only private CAs make sense.
If you want to try using a private CA for x509 certificates to do SSH client authentication, I know of a couple solutions that make it easy to do:
Smallstep: https://smallstep.com/docs/tutorials/ssh-certificate-login/
Infiniscal: https://infisical.com/docs/documentation/platform/ssh/overvi...
You can also do it the hard way. For example, here's how it can be done to SSH into Cisco network gear: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9...