[HN Gopher] Upcoming changes to Let's Encrypt and how they affec...
___________________________________________________________________
Upcoming changes to Let's Encrypt and how they affect XMPP server
operators
Author : zaik
Score : 56 points
Date : 2026-02-09 20:31 UTC (2 hours ago)
(HTM) web link (blog.prosody.im)
(TXT) w3m dump (blog.prosody.im)
| PunchyHamster wrote:
| Shame LE didn't give people option to generate client and
| client+server auth certs
| forty wrote:
| Yes, but then the lack of pragmatism shown by the XMPP
| community is a bit disconcerting
| superkuh wrote:
| It is not pragmatic to design your protocol for web use cases
| when it's not the web.
| bawolff wrote:
| Unless im missing something, this is a poor design full
| stop. How are they validating SAN on these client
| certificates?
| agwa wrote:
| XMPP identifiers have domain names, so the XMPP server
| can check that the DNS SAN matches the domain name of the
| identifiers in incoming XMPP messages.
|
| I've seen non-XMPP systems where you configure the DNS
| name to require in the client certificate.
|
| It's possible to do this securely, but I agree entirely
| with your other comment that using a public PKI with
| client certs is a recipe for disaster because it's so
| easy and common to screw up.
| SahAssar wrote:
| What is the lack of pragmatism you are talking about?
| jammcq wrote:
| 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.
| RobotToaster wrote:
| Why did LE make this change? It feels like a rather deliberate
| attack on the decentralised web.
| duskwuff wrote:
| 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.
| mhurron wrote:
| 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 wrote:
| Google forced separate client and server PKIs.[1]
|
| [1] https://letsencrypt.org/2025/05/14/ending-tls-client-
| authent...
| ameliaquining wrote:
| 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.
| kej wrote:
| >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 wrote:
| 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 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| xg15 wrote:
| How is "client certificates forbidden" in any way an
| improvement?
| xg15 wrote:
| 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.
| everfrustrated wrote:
| 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 wrote:
| 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.
| josephcsible wrote:
| > they just decided it wasn't worth the effort anymore
|
| That seems disingenuous. Doesn't being in the client cert
| business now require a lot of extra effort that it didn't
| before, due entirely to Google's new rule?
| everfrustrated wrote:
| Feel free to start your own non-profit to issue client certs
| signed by a public authority.
|
| As LE says, most users of client certs are doing mtls and so
| self-signed is fine.
| nickf wrote:
| Publicly-trusted client authentication does nothing. It's not
| a thing that should exist, or is needed.
| abnormalitydev wrote:
| 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.
| bawolff wrote:
| 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 wrote:
| 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.
| xg15 wrote:
| It seems reasonable for server-to-server auth though? Suppose
| my server xmpp.foo.com already trusts the other server
| xmpp.bar.com. Now I get some random incoming connection. How
| would I verify that this connection indeed originates from
| xmpp.bar.com? LE-assigned client certs sound like a good
| solution to that problem.
| benjojo12 wrote:
| 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
| nickf wrote:
| Client authentication with publicly-trusted (i.e. chaining to
| roots in one of the major 4 or 5 trust-store programs) is bad. It
| doesn't actually authenticate anything at all, and never has.
|
| No-one that uses it is authenticating anything more than the
| other party has an internet connection and the ability, perhaps,
| to read. No part of the Subject DN or SAN is checked. It's just
| that it's 'easy' to rely on an existing trust-store rather than
| implement something secure using private PKI.
|
| Some providers who 'require' public TLS certs for mTLS even
| specify specific products and CAs (OV, EV from specific CAs) not
| realising that both the CAs and the roots are going to rotate
| more frequently in future.
| ajross wrote:
| A client cert can be stored, so it provides at least a little
| bit of identification certainty. It's very hard to steal or
| impersonate a specific client cert, so the site has a high
| likelihood of knowing you're the same person you were when you
| connected before (even though the initial connection may very
| well not have ID'd the correct person!). That has value.
|
| But it also doesn't involve any particular trust in the CA
| either. Lets Encrypt has nothing to offer here so there's no
| reason for them to try to make promises.
___________________________________________________________________
(page generated 2026-02-09 23:00 UTC)