Inabiltiy to s2s on next generation letsencrypt certifiates (X509v3 Extended Key Usage: ONLY TLS Web Server Authentication)

[Menelmacar]

Bug description

When generating a letsencrypt certificate with the tlsserver ACME profile to mimic the future of letsencrypt (see https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/ ) then my prosody server can't to any s2s with ejabberd servers anymore:

From the log: info SASL EXTERNAL with conference.siacs.eu failed: error<cancel:not-authorized:unsupported certificate purpose>

It seems prosody already has a workaround for this, allowing these certificates for s2s regardless. It would be good to allow letsencrypt with ejabberd in the future too, even with these limited certificates, since they will be realistically the only choice for some people.

Edit: it seems basically all free acme root CAs will do the same, it's some googpe policy that's needed for them to be in Google chrome in the future. And apparently these companies can't afford to have a second root for client certificates.

If I allow dialback, then I can connect regardless

[licaon-kter]

you use client certificate for your server?

[Menelmacar]

Indeed. As far as I understand it myself servers authenticate as clients to other servers and this is an issue for a lot of software. See smtp. This seems to be the future of letsencrypt, and other acme CAs, so it would be good if xmpp servers adapt. Further reading : https://community.letsencrypt.org/t/do-not-remove-tls-client-auth-eku/237427 https://toot.mirbsd.org/@mirabilos/statuses/01JWV4CFRPC33MZHQN2TWYKJQD etc

EDIT: I used the lego acme clinet to get such a cert btw.. if someone want to test this themself. (using "run" with --profile tlsserver )

[mirabilos]

This is a bug in the CA policies that will ruin all certificates issued by CAs in the Google Chrome root store (which OS’ CA bundles will likely follow) for SMTP and XMPP and the likes by removing the TLS client auth key usage.

The thread around web+ap://toot.mirbsd.org/@mirabilos/statuses/01JWV4CFRPC33MZHQN2TWYKJQD has more infos and references.

Counter-acting Google by changing SSL to not look at the key usages any more seems…

… the way out, actually, tbh. Perhaps suggest that to OpenSSL, nōnGnuTLS, NSS, etc.?

[moparisthebest]

ejabberd can work around this easily enough, in fact I was told in the MUC weeks ago it already had... But that code must have bitrotted during the LE years when no one was testing it.

we'll get all the servers fixed before LE pulls the switch

[mirabilos]

On Tue, 3 Jun 2025, Travis Burtrum wrote:

we'll get all the servers fixed before LE pulls the switch

You’ll not.

You can try to get all the code fixed, but not servers, due to distribution lifecycles, and all that.

[erebion]

Questions important for everyone hosting:

• When will it break without a fix?
• What can I, as an admin, do to avoid the breakage until there's a real fix?

[weiss]

What can I, as an admin, do to avoid the breakage until there's a real fix?

Enable mod_s2s_dialback (and tell remote server admins to do the same in case of s2s auth failure).

[Menelmacar]

@erebion See my first link for the timeline. https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/ February 11, 2026: the default classic ACME profile will no longer contain the Client Authentication EKU.

So it will likely break from Feb 11 for everyone not paying attention. And three months later if one did. Dialback, as mentioned, seems a good bandaid until a better solution is in place.

[erebion]

Enable mod_s2s_dialback (and tell remote server admins to do the same in case of s2s auth failure).

Any specific way I can tell other than messages from those servers not arriving or looking deep in the logs?

[licaon-kter]

You'll see certificate related errors if the other server rejects yours.

[agowa]

Or what do you think about "patching" the validation to instead of checking for "clientAuth" it checks also for "serverAuth" in the certificate received from the server?

The argument mainly is that "clientAuth" is supposed to be for user authentication e.g. smart card login and such. But we're doing server-to-server here, so why not bend the rules a bit and let the received TLS-client certificate be validated as if it was "just another server cert" instead? By that the libraries would be looking for "serverAuth" instead of "clientAuth" with little change. (Could be hard in practice though as probably the entire tls connection establishment is within the tls library so it would need a change within them too then)

[prefiks]

I added 72bc9b6c7f6afce7aa671a47eee343cc25b0abcb that should allow such certificate be accepted by ejabberd.