Problème (de certificat) sur les conversations à plusieurs XMPP

Salut !

J’ai un souci avec les conversations XMPP sur YunoHost 4.3.6.3 : un camarade n’arrive pas à accéder à muc.MAINDOMAIN à cause d’un souci de certificat. J’ai Let’s Encrypt activé, et je n’ai touché à rien ni côté certificats, ni sur ce domaine côté XMPP (j’ai modifié la conf’ d’un domaine secondaire pour accepter les connexions anonymes, mais je ne pense pas que ça joue à ce niveau).

Je n’y connais pas forcément énormément, donc voilà les infos remontées par le camarade en question lors d’une tentative de diagnostique :

J’ai un souci pour rejoindre la conversation : « Server-to-server connection failed: Remote server’s certificate is not valid for this name »

Ah, le message d’erreur semble avoir raison. Avec openssl je récupère bien un certificat pour MAINDOMAIN, mais aucun pour muc.MAINDOMAIN

Ah, encore plus piégeux en fait : il y a bien un certificat fourni pour la communication de serveur à serveur (port 5269), mais pas pour la communication de client à serveur (port 5222).

Et j’ai peut-être trouvé : celui fourni pour les serveurs n’est pas valide pour le sous-domaine muc.*

Pour info, la commande qui m’a permis de retrouver ledit certificat :
openssl s_client -connect muc.MAINDOMAIN:5269 </dev/null -starttls xmpp-server

Pour info je viens de tester un autre client XMPP, mais le souci est bien au niveau de la communication entre serveurs, je continue à recevoir la même erreur.

Le plus étrange était qu’il n’y avait auparavant aucun problème de communication entre nos deux serveurs, il a déjà rejoint des conversations sur mon serveur auparavant, et on n’a a priori rien changé de spécial ni l’un ni l’autre depuis. Donc je ne pige pas tout et vos lumières seraient les bienvenues.

Je suppose que redémarrer le service metronome ne change rien ?
Idem si tu régénères la configuration ?

yunohost regen-conf metronome
cat /etc/metronome/conf.d/DOMAIN.cfg.lua

Arf, désolé, j’avais loupé ta réponse.

J’ai redémarré le serveur entier entre temps, mais le problème semble persister.

regen-conf me signale que le fichier pour le domaine secondaire est modifié, mais rien pour celui du domaine principal, le fichier est le même avant et après.

As tu essayé de renouveler plus tôt le certif let’s encrypt ?

T’as peut être raison sur ce point, le certifs vaut pour DOMAIN et xmpp-upload.DOMAIN, pas les autres.

Je t’avoue que je ne sais pas comment fonctionne muc, mais tu as sans doute raison.

SI tu veux faire un test en modifiant la génération du certificat et faire une Pull Request pour corriger ça, n’hésites pas:

Your issue:Muc XMPP use cert without muc.DOMAIN · Issue #2036 · YunoHost/issues · GitHub

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.