XMPP Service Operators - 2026-06-02

Hey all! I am told by someone that my prosody config regarding certificates and s2s for slidge.im is too strict and prevents them from joining my MUC. They use something similar to https://account.conversations.im/domain/ (but with another provider). Does someone here use something similar? If yes, could be please try to join, eg, xmpp:support@rooms.slidge.im?join to see if there is something wrong with my setup? Thanks in advance.

Be specific

> Hey all! I am told by someone that my prosody config regarding certificates and s2s for slidge.im is too strict and prevents them from joining my MUC. They use something similar to https://account.conversations.im/domain/ (but with another provider). Does someone here use something similar? If yes, could be please try to join, eg, xmpp:support@rooms.slidge.im?join to see if there is something wrong with my setup? Thanks in advance. Perhaps just post the relevant sections from the config :)

> Hey all! I am told by someone that my prosody config regarding certificates and s2s for slidge.im is too strict and prevents them from joining my MUC. They use something similar to https://account.conversations.im/domain/ (but with another provider). Does someone here use something similar? If yes, could be please try to join, eg, xmpp:support@rooms.slidge.im?join to see if there is something wrong with my setup? Thanks in advance. I just joined fine. Not sure how helpful that is. ↺

^ srry got too keen, am not with a similar provider heh.

Specifically, in my logs I see s2s failed because the certificate is not valid for their domain. I have `s2s_secure_auth = true` in my prosody. I very highly suspect that _their_ configuration is wrong, but since my knowledge about certificates is very limited, I wonder.

nicoco: does the server's cert read as expired if you go download it or curl the site or something?

> warn Forbidding insecure connection to/from neverseen.de because its certificate is not valid for this name This is the error I get. On another prosody instance I administrate, I have `s2s_secure_auth = false` and I can reach them. This is documented here <https://prosody.im/doc/s2s#security> Should I set `s2s_secure_auth = true` on my other server too? What are the implications of having this to `false`? Is is expected that enabling it prevents "domain hosted"-users to connect or is it some misconfiguration on their side?

> > warn Forbidding insecure connection to/from neverseen.de because its certificate is not valid for this name > This is the error I get. On another prosody instance I administrate, I have `s2s_secure_auth = false` and I can reach them. This is documented here <https://prosody.im/doc/s2s#security> > Should I set `s2s_secure_auth = true` on my other server too? What are the implications of having this to `false`? Is is expected that enabling it prevents "domain hosted"-users to connect or is it some misconfiguration on their side? Connecting to a server with incorrect TLS configuration should not be something you generally enable. At most it should be a workaround if you cannot reach it otherwise. I know there's a way of only accepting that for specific hosts, that seems much more sensible. Everything else is just "disable cert verification so it works", which is not a good idea. ↺

Thanks. So, it is possible for "domain hosted" users to connect to a prosody instance that has `s2s_secure_auth = true`, provided their certs and dns are properly configured, right?

Yes, this is only because of their cert issue.

I have that exact line in my conf also.

You have to provide a cert for the server name. I guess conversations.im has a FAQ somewhere explaining it.

Maybe you could enable dialback as a workaround.

Thanks for your replies. I'm not looking for a workaround, I just wanted to make sure my config was right.

You want to keep s2s_secure_auth = true. It forces remote servers to prove their identity using trusted TLS certificates, preventing spoofing and ensuring that your federated chat traffic is always encrypted and authenticated. This is the XMPP promise. I have this enabled on my server.

> Maybe you could enable dialback as a workaround. Could, but not a good idea. Seems trivial to do some intercepting of TLS traffic, as the server just dials back and then the attacker just communicates in both directions. Just use valid certs.

I, for one, do not enable dialback.

Me neither

I had to enable it for older ejabberds.

fixed ejabberd is even in debian stable now so no need for that just harass them to upgrade their woefully insecure servers (anyone who hasn't upgraded in the last week or so has a ton of serious CVEs to patch)

> fixed ejabberd is even in debian stable now so no need for that just harass them to upgrade their woefully insecure servers (anyone who hasn't upgraded in the last week or so has a ton of serious CVEs to patch) Or just get a shell via RCE and update it yourself, lol /s

lol likely possible

and illegal

erebion, are you using SAN certificates??

> fixed ejabberd is even in debian stable now so no need for that just harass them to upgrade their woefully insecure servers (anyone who hasn't upgraded in the last week or so has a ton of serious CVEs to patch) moparisthebest, You know this is probably like, half the XMPP network 🤣 ↺

>> warn Forbidding insecure connection to/from neverseen.de because its certificate is not valid for this name > This is the error I get. On another prosody instance I administrate, I have `s2s_secure_auth = false` and I can reach them. This is documented here <https://prosody.im/doc/s2s#security> > Should I set `s2s_secure_auth = true` on my other server too? What are the implications of having this to `false`? Is is expected that enabling it prevents "domain hosted"-users to connect or is it some misconfiguration on their side? If a security system is flagging you investigate not just turn it off. Its failing for a reason to protect you ↺

I assume the issue could be that erebion's certificate doesn't have all the domains in use within it, and when peering the certificate doesn't match the host which nicoco's server is connected to.

icebound.dev, erebion just helped me here by replying, they are not involved in this certificate issue.

> icebound.dev, erebion just helped me here by replying, they are not involved in this certificate issue. Oh? I thought you said you were having issues with connecting to their server. Sorry. ↺

I misunderstood

What server is the issue then?

> If a security system is flagging you investigate not just turn it off. Its failing for a reason to protect you Sure, also my reasoning, it's just that the other party insisted that _my_ server was misconfigured and since I am not entirely sure about the implications of all this, it got me wondering and come here to ask is all :) ↺

lemme yoink the certificate using openssl s_client and see if my hypothesis is correct

I need to know the domain though :p

domain is neverseen.de, and don't bother, the issue is on their side, I'm now pretty much sure. It's on them to do the fixing if they feel like it :)

>> If a security system is flagging you investigate not just turn it off. Its failing for a reason to protect you > Sure, also my reasoning, it's just that the other party insisted that _my_ server was misconfigured and since I am not entirely sure about the implications of all this, it got me wondering and come here to ask is all :) Which domain can't be verified? Can you verify other domains? Which cacert store did you install? Mozilla's? ↺

> lemme yoink the certificate using openssl s_client and see if my hypothesis is correct Testssl.sh includes a starttls for xmpp. You could use that too. ↺

> fixed ejabberd is even in debian stable now so no need for that just harass them to upgrade their woefully insecure servers (anyone who hasn't upgraded in the last week or so has a ton of serious CVEs to patch) I already nag Holger every now and then. 😁

> Which domain can't be verified? Can you verify other domains? Which cacert store did you install? Mozilla's? thanks for trying to help but as I have said, I'm good now, I got my answers, it's somebody else's problem now :) ↺

What's that "non of serious CVEs to patch", how does ejabberd allow you to get a shell? I'm not aware of a single serious issue.

> xmpp-dns -st neverseen.de > xmpp-server jabber.hot-chilli.net. 5269 > Priority: 0 Weight: 0 > IP: 49.12.125.53 > Test: [Not OK] > tls: failed to verify certificate: x509: certificate is valid for hot-chilli.net, not neverseen.de > IP: 2a01:4f8:242:56ca::2 > Test: [Not OK] > tls: failed to verify certificate: x509: certificate is valid for hot-chilli.net, not neverseen.de

If I missed that, I'd be super-thankful for the information.

If I didn't miss it, I'd be thankful for not spreading misinformation in channels like this one.

I guess they assume you also didn't update the system if you operate an old ejabberd.

Yes but I'm not even aware of a single remote exploits or anything similar serious for any ejabberd release of the past several years.

Let alone "a ton'>

I guess they don't think ejabberd has those issues but assume you haven't installed the recent security fixes of the Linux kernel, bind and so on.

Don't get me wrong, I'm all for updating whenever possible, and I'm all for addressing anything remotely security-related. But misinformation isn't helpful for taking security serious, IMO. (Not saying this is misinformation, my question what I have missed wasn't meant rhetorically!)

Martin: Ahh.

> and illegal That's why I included "lol" and "/s". Otherwise it could be seen as invoking a criminal offence. This way it is just a joke, if you know what that is. :D

Jokes? We don't do that here. /s

Martin: That would be a wild assumption, and I hadn't read the messages above that way.

Holger: I just meant anyone who hasn't upgraded with their package manager in the last week have a ton of unpatched CVEs, and even on debian stable that's enough to get you the ejabberd cert fix

True that.

nicoco, yeah I was right

its because its not a SAN certificate

its only valid for `subject=CN=jabber.hot-chilli.net`

which is where the SRV record points, but the FQDN's of all the accounts and services need to be listed

surprisingly they do support TLSv1.3, some server admins here have yet to make the jump :p

You know who you are!

heh

> I, for one, do not enable dialback. Me neither. Never. ↺

> Me neither. Never. Hello! How do I do that on Prosody? Just disable mod_dialback? Are there potential risks/negative effects I should consider? Thanks!!

whats dialback? Never heard of it :p

(kidding)

gt: yes disable the module, the effect will be you can only federate with servers that have valid trusted certificates, and you need a valid certificate

> gt: yes disable the module, the effect will be you can only federate with servers that have valid trusted certificates, and you need a valid certificate Thanks!

> > Me neither. Never. > > Hello! > How do I do that on Prosody? Just disable mod_dialback? > Are there potential risks/negative effects I should consider? > Thanks!! If "dialback"; is in modules_enabled, remove it or comment it out and it will be gone. And you want these in the global config: # Force Prosody to validate the TLS certificates s2s_secure_auth = true # Force encryption for both clients and servers s2s_require_encryption = true c2s_require_encryption = true ✏ ↺