This category is for general issues(=something is broken) regarding YunoHost, NOT apps.
on
This form is written in English but feel free to write in French if you’re more comfortable!
on
What type of hardware are you using
VPS bought online
What YunoHost version are you running
12.1.41.2
How are you able to access your server
The webadmin
Are you in a special context or did you perform specific tweaking on your YunoHost instance ?
Using YunoHost LDAP backend for XMPP (PLAIN mechanism) with Prosody.
Describe your issue
Since recent updates (especially with strict F-Droid builds of Conversations), attempting to connect to XMPP on a YunoHost server using the LDAP backend triggers a TLS 1.3 / channel binding failure.
Prosody logs show:
“Channel binding ‘tls-unique’ undefined in context of TLS 1.3”
Conversations rejects the connection outright during SASL negotiation because it expects a channel binding under TLS 1.3 while using the PLAIN mechanism required for LDAP authentication. Since typical users cannot easily tweak advanced connection settings/ports on mobile clients, this creates a deadlock for self-hosted instances using LDAP authentication.
Share relevant logs or error messages
c2s5b82b40: Channel binding ‘tls-unique’ undefined in context of TLS 1.3
c2s5b82b40: SASL mechanisms supported by handler: PLAIN
c2s5b82b40: Offering usable mechanisms: PLAIN
c2s5b82b40: Destroying unbound session for <(unknown)@peripheria.org>
Hit the same Prosody log on a YH instance that still uses LDAP-backed PLAIN for XMPP: Channel binding 'tls-unique' undefined in context of TLS 1.3, then the session dies during SASL.
What helped as a short-term client-side workaround (not a server fix): in Conversations, turn off the option that forces channel binding / “require channel binding” (wording varies by build). After that, PLAIN over TLS 1.3 can complete again on the F-Droid builds that started rejecting the missing binding.
That matches what others reported here. It does not restore SCRAM or proper channel binding — LDAP credential storage still limits the usable SASL set to PLAIN — so it is only a way to keep mobile clients connecting until the LDAP/SCRAM work lands.
Also curious whether YH 13 / sssd changes the picture for Prosody auth, or if XMPP stays on the same PLAIN path for now.