7 ms·

Why did LE make this change? It feels like a rather deliberate attack on the decentralised web.

duskwuff 8mo ago
Not precisely an answer, but there's some related discussion here: https://cabforum.org/2025/06/11/minutes-of-the-f2f-65-meeting-in-toronto-canada-scwg-june-11-2025/#discussion-about-removal-of-clientauth-keypurposeid 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.
mhurron 8mo ago
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-authentication https://letsencrypt.org/2025/05/14/ending-tls-client-authent...
pseudalopex 8mo ago
Google forced separate client and server PKIs.[1] [1] https://letsencrypt.org/2025/05/14/ending-tls-client-authentication https://letsencrypt.org/2025/05/14/ending-tls-client-authent...
ameliaquining 8mo ago
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-forward-together/#phase-out-multi-purpose-roots-from-the-chrome-root-store 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.
- kej 8mo ago
  >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 Do you (or anyone else) have an example of this happening?
  - agwa 8mo ago
    After the WebPKI banned the issuance of new SHA-1 certificates due to the risk of collisions, several major payment processors (Worldpay[1], First Data[2], TSYS[3]) demanded to get more SHA-1 certificates because their customers had credit card terminals that did not support SHA-2 certificates. They launched a gross pressure campaign, trotting out "small businesses" and charity events that would lose money unless SHA-1 certificates were allowed. Of course, these payment processors did billions in revenue per year and had years to ship out new credit card terminals. And small organizations could have and would have just gotten a $10 Square reader at the nearest UPS store if their credit card terminals stopped working, which is what the legacy payment processors were truly scared of. The pressure was so strong that the browser vendors ended up allowing Symantec to intentionally violate the Baseline Requirements and issue SHA-1 certificates to these payment processors. Ever since, there has been a very strong desire to get use cases like this out of the WebPKI and onto private PKI where they belong. A clientAuth EKU is the strongest indicator possible that a certificate is not intended for use by browsers, so allowing them is entirely downside for browser users. I feel bad for the clientAuth use cases where a public PKI is useful and which aren't causing any trouble (such as XMPP) but this is ultimately a very tiny use case, and a world where browsers prioritize the security of ordinary Web users is much better than the bad old days when the business interests of CAs and their large enterprise customers dominated. [1] https://groups.google.com/g/mozilla.dev.security.policy/c/RHBHXJOG8Io/m/5_H_NzZhAQAJ https://groups.google.com/g/mozilla.dev.security.policy/c/RH... [2] https://groups.google.com/g/mozilla.dev.security.policy/c/yhq6QNhEQok/m/9sdadL9kFwAJ https://groups.google.com/g/mozilla.dev.security.policy/c/yh... [3] https://groups.google.com/g/mozilla.dev.security.policy/c/LM9tkZR9mLM/m/ACBIRX7GAAAJ https://groups.google.com/g/mozilla.dev.security.policy/c/LM...
    - 8mo ago
gumarn_y 8mo ago
Imho because to put both into a certificate just by convention (or what was the reason to still do it?) is for a CA that has the webpki in scope is not best practice. From experience people are often misleading the client authentication part as a substitute for user authentication what you simply don't get and than they are surprised that anyone with the certificate can login... Yeah people with knowledge should know the difference but I have seen this way too many times...The thing I really see LE is problematic is the topic of revocation. Yes revocation is broken but the only working mechanism with ocsp stapling was brought to the graveyard (aka made optional by the cab) with the argument of data privacy issues under the normal ocsp umbrella...Yeah back to CRLs/proprietary browser revocation mechanisms such as CRLsets (https://www.grc.com/revocation/crlsets.htm#:~:text=What%20is%20Chrome's%20CRLSet?,not%20contain%20all%20revoked%20certificates%E2%80%9D. https://www.grc.com/revocation/crlsets.htm#:~:text=What%20is...) combined with CTlogs as a reactive measure that simply don't work in practice/are too slow (e.g. remember the Fina CA/Cloudflare incident and the time it went unnoticed). I have the feeling the driver for LE were rather the costs than the data privacy arguments brought up.

Not precisely an answer, but there's some related discussion here: https://cabforum.org/2025/06/11/minutes-of-the-f2f-65-meeting-in-toronto-canada-scwg-june-11-2025/#discussion-about-removal-of-clientauth-keypurposeid 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.

mhurron 8mo ago

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-authentication https://letsencrypt.org/2025/05/14/ending-tls-client-authent...

pseudalopex 8mo ago

Google forced separate client and server PKIs.[1] [1] https://letsencrypt.org/2025/05/14/ending-tls-client-authentication https://letsencrypt.org/2025/05/14/ending-tls-client-authent...

ameliaquining 8mo ago

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-forward-together/#phase-out-multi-purpose-roots-from-the-chrome-root-store 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.

kej 8mo ago
>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 Do you (or anyone else) have an example of this happening?
- agwa 8mo ago
  After the WebPKI banned the issuance of new SHA-1 certificates due to the risk of collisions, several major payment processors (Worldpay[1], First Data[2], TSYS[3]) demanded to get more SHA-1 certificates because their customers had credit card terminals that did not support SHA-2 certificates. They launched a gross pressure campaign, trotting out "small businesses" and charity events that would lose money unless SHA-1 certificates were allowed. Of course, these payment processors did billions in revenue per year and had years to ship out new credit card terminals. And small organizations could have and would have just gotten a $10 Square reader at the nearest UPS store if their credit card terminals stopped working, which is what the legacy payment processors were truly scared of. The pressure was so strong that the browser vendors ended up allowing Symantec to intentionally violate the Baseline Requirements and issue SHA-1 certificates to these payment processors. Ever since, there has been a very strong desire to get use cases like this out of the WebPKI and onto private PKI where they belong. A clientAuth EKU is the strongest indicator possible that a certificate is not intended for use by browsers, so allowing them is entirely downside for browser users. I feel bad for the clientAuth use cases where a public PKI is useful and which aren't causing any trouble (such as XMPP) but this is ultimately a very tiny use case, and a world where browsers prioritize the security of ordinary Web users is much better than the bad old days when the business interests of CAs and their large enterprise customers dominated. [1] https://groups.google.com/g/mozilla.dev.security.policy/c/RHBHXJOG8Io/m/5_H_NzZhAQAJ https://groups.google.com/g/mozilla.dev.security.policy/c/RH... [2] https://groups.google.com/g/mozilla.dev.security.policy/c/yhq6QNhEQok/m/9sdadL9kFwAJ https://groups.google.com/g/mozilla.dev.security.policy/c/yh... [3] https://groups.google.com/g/mozilla.dev.security.policy/c/LM9tkZR9mLM/m/ACBIRX7GAAAJ https://groups.google.com/g/mozilla.dev.security.policy/c/LM...
  - 8mo ago

gumarn_y 8mo ago

Imho because to put both into a certificate just by convention (or what was the reason to still do it?) is for a CA that has the webpki in scope is not best practice. From experience people are often misleading the client authentication part as a substitute for user authentication what you simply don't get and than they are surprised that anyone with the certificate can login... Yeah people with knowledge should know the difference but I have seen this way too many times...The thing I really see LE is problematic is the topic of revocation. Yes revocation is broken but the only working mechanism with ocsp stapling was brought to the graveyard (aka made optional by the cab) with the argument of data privacy issues under the normal ocsp umbrella...Yeah back to CRLs/proprietary browser revocation mechanisms such as CRLsets (https://www.grc.com/revocation/crlsets.htm#:~:text=What%20is%20Chrome's%20CRLSet?,not%20contain%20all%20revoked%20certificates%E2%80%9D. https://www.grc.com/revocation/crlsets.htm#:~:text=What%20is...) combined with CTlogs as a reactive measure that simply don't work in practice/are too slow (e.g. remember the Fina CA/Cloudflare incident and the time it went unnoticed). I have the feeling the driver for LE were rather the costs than the data privacy arguments brought up.