For those wondering if ejabberd Debian systems will be impacted, it seems like for now there no fix, the issue is being tracked here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1127369

I like how the article describes how certificates work for both client and server. I know a little bit about it but what I read helps to reinforce what I already know and it taught me something new. I appreciate it when someone takes the time to explain things like this.

I feel like using web pki for client authentication doesn't really make sense in the first place. How do you verify the common name/subject alt name actually matches when using a client cert.

Using web pki for client certs seems like a recipe for disaster. Where servers would just verify they are signed but since anyone can sign then anyone can spoof.

And this isn't just hypothetical. I remember xmlsec (a library for validating xml signature, primarily saml) used to use web pki for signature validation in addition to specified cert, which resulted in lot SAML bypasses where you could pass validation by signing the SAML response with any certificate from lets encrypt including the attackers.

• nickf

  today at 10:40 PM

  You are correct, and the answer is - no-one using publicly-trusted TLS certs for client authentication is actually doing any authentication. At best, they're verifying the other party has an internet connection and perhaps the ability to read.

  It was only ever used because other options are harder to implement.

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

• ameliaquining

  today at 9:41 PM

  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.

  • xg15

    today at 10:41 PM

    This sounds a lot like the "increasing hostility for non-web usecases" line in the OP.

    In theory, Chrome's rule would split the CA system into a "for web browsers" half and a "for everything else" half - but in practice, there might not be a lot of resources to keep the latter half operational.

  • kej

    today at 9:48 PM

    >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

      today at 10:40 PM

      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 campaign 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 vendors. 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/RH...

      [2] https://groups.google.com/g/mozilla.dev.security.policy/c/yh...

      [3] https://groups.google.com/g/mozilla.dev.security.policy/c/LM...

  • detourdog

    today at 9:51 PM

    I’m disappointed that a competitor doesn’t exist that uses longevity of IP routing as a reputation validator. I would think maintaining routing of dns to a static IP is a better metric for reputation. Having unstable infrastructure to me is a flag for fly by night operations.

    • ocdtrekkie

      today at 10:08 PM

      Well, be prepared for certificates that change every 7 to 47 days, as the Internet formally moves to security being built entirely on sand.

      • webstrand

        today at 10:33 PM

        I wonder if this is a potential "off switch" for the internet. Just hit the root ca so they can't hand out the renewed certificates, you only have to push them over for a week or so.

        • gus_massa

          today at 10:38 PM

          People will learn to press all the buttons with scarry messages to ignore the wrong certificates. It may be a problem for credit cards and online shopping.

  • RobotToaster

    today at 10:17 PM

    Isn't LE used for half the web at this point?

    Calling Google's bluff and seeing if they would willingly cut their users off from half the web seems like an option here.

    • bawolff

      today at 10:28 PM

      That's not how this would work.

      Based on previous history where people actually did call google's bluff to their regret, what happens is that google trusts all current certificates and just stops trusting new certs as they are issued.

      Google has dragged PKI security into the 21st century kicking and screaming. Their reforms are the reason why PKI security is not a joke anymore. They are definitely not afraid to call CA companies bluff. They will win.

• mhurron

  today at 9:38 PM

  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...

• pseudalopex

  today at 9:38 PM

  Google forced separate client and server PKIs.[1]

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

• duskwuff

  today at 9:36 PM

  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.

Shame LE didn't give people option to generate client and client+server auth certs

• forty

  today at 9:28 PM

  Yes, but then the lack of pragmatism shown by the XMPP community is a bit disconcerting

  • superkuh

    today at 9:51 PM

    It is not pragmatic to design your protocol for web use cases when it's not the web.

    • bawolff

      today at 10:39 PM

      Unless im missing something, this is a poor design full stop. How are they validating SAN on these client certificates?

Is there any reason why things gravitate towards being web-centric, especially Google-centric? Seeing that Google's browser policies triggered the LE change and the fact that most CAs are really just focusing on what websites need rather than non-web services isn't helpful considering that browsers now are terribly inefficient (I mean come on, 1GB of RAM for 3 tabs of Firefox whilst still buffering?!) yet XMPP is significantly more lightweight and yet more featureful compared to say Discord.

From https://letsencrypt.org/2025/05/14/ending-tls-client-authent...

"This change is prompted by changes to Google Chrome’s root program requirements, which impose a June 2026 deadline to split TLS Client and Server Authentication into separate PKIs. Many uses of client authentication are better served by a private certificate authority, and so Let’s Encrypt is discontinuing support for TLS Client Authentication ahead of this deadline."

TL;DR blame Google

• bawolff

  today at 10:11 PM

  Google didn't force lets encrypt to totally get out of the client cert business, they just decided it wasn't worth the effort anymore.