jMQTT et paramètres de sécurité broker

[tomdom]

Il me semble que depuis un moment, je t’avais demandé si tu arrivais à te connecter sans certificat client …
Car le problème est justement là depuis là depuis le début.
Donc soit il y a un problème avec le copier/coller, soit avec le mot de passe de la clé privée La bibliothèque qu’utilise le plugin considère ton triptyque Certficat/Clé/Mot de passe invalide

Édit : n’utilisant pas cette partie là, je n’avais pas vu que l’on ne pouvat pas fournir le mot de passe de la clé. Donc, est-ce que la clé privée est en clair (non protégée par un mot de passe) ?

Édit le retour : surtout qu’avec mqtt-explorer, tu n’utilises pas de certificat client il me semble ?

[oracle7]

@tomdom

Il me semble que depuis un moment, je t’avais demandé si tu arrivais à te connecter sans certificat client

Je t’invite à relire ma réponse (poste 13) qui suivait ta question. Non Pas de connexion.

@tomdom

Ok. Donc sans certificat client (Certificat client non coché), ça doit fonctionner avec jmqtt sur le port 8883 en utilisant le nom RPI-OUTILS

Idem voir ma réponse + copie d’écran (poste 21) qui suit la question. Non Pas de connexion

@tomdom

Donc soit il y a un problème avec le copier/coller, soit avec le mot de passe de la clé privée

Avec le C/C je ne pense pas, j’y suis assez vigilant car on peut prendre des caractères invisibles qui sont en fait interprétés par le système et qui le font « planter » ou avoir un comportanment erratique ensuite. De toutes fàçons je ne fait JAMAIS de C/C de MdP. Je les saisi manuellement systématiquement par soucis de sécurité.

Par contre, il pourrait y avoir effectivement un problème peut-être et éventuellement (quoi que) avec le mot de passe de la clé privée de mon certificat de l’autorité CA. En effet, celui-ci fait 17 caractères et d’expérience Jeedom ne semble pas aimer les MdP > 12 caractères. J’ai déjà fait ce constat avec le MdP de mes sauvegardes Jeedom via Samba que j’ai du réduire à moins de 12 caractères pour que ces sauvegardes soient finalement effectives. Cela pourrait être une piste …

@tomdom

est-ce que la clé privée est en clair (non protégée par un mot de passe) ?

Pour ce qui est de la clé privée pour les certificats serveur et client (Jeedom notamment), celles-ci ont été générées SANS mot de passe conformément à de multiples recommandatons trouvées dans différents TUTOs sur la toile (notamment dans celui-ci https://openest.io/linux-embarque/communication-linux/chiffrement-communication-mqtt-tls-ssl-mosquitto-et-paho/ ).

@tomdom

surtout qu’avec mqtt-explorer, tu n’utilises pas de certificat client il me semble ?

Eh bien, désolé mais NON, j’utilise comme je te l’ai déjà précisé précédemment (à la fin du poste 23) un certificat CA et une paire certificat/clé privée pour le client dans ma connexion avec MQTT Explorer :

Je le répète, j’utilise exactement les mêmes pour la configurations du broker dans le plugin jMQTT.
Donc pour moi le problème est bien ailleurs qu’avec ces certificats …

[tomdom]

@oracle7

Je t’invite à relire ma réponse (poste 13) qui suivait ta question. Non Pas de connexion.

Sauf que la connexion ne se faisait pas car tu mettais l’adresse ip et non le nom d’hôte

@oracle7

Cela dit cela ne passe pas non plus avec l’@IP sur serveur MQTT…

3 - Par ailleurs, si je ne précise pas de certificat client , j’obtiens cette erreur :

[2022-12-19 13:30:36,947]ERROR Client466       MainThread           start() : Could not start MQTT client: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: IP address mismatch, certificate is not valid for '192.168.2.52'. (_ssl.c:1056)

Et donc ce n’était pas la même erreur

[oracle7]

@tomdom

Et donc ce n’était pas la même erreur

On est d’accord, ce cas de figure est encore autre chose et somme toute c’est une « erreur normale » qui est retournée dans la mesure où si on veux une connexion sécurisée avec validation par certificat, ce dernier doit être obligatoirement précisé. Je l’ai compris comme cela …

Dans tous les cas, il n’en reste pas moins un problème avec le port 8883 qui actuellement si spécifié, bloque (empêche) la connexion sécurisée. C’est mon constat.

[tomdom]

Justement non. Ce qui bloque c’est uniquement la partie certificat client.
La connexion chiffrée elle doit fonctionner. Seule l’authentification forte ne fonctionne pas.

C’est pour ça que si tu refais un test sans le certificat client et en mettant le nom d’hôte de ton serveur mqtt au lieu de l’adresse ip, il ne devrait pas y avoir de problème avec le port 8883

[oracle7]

@tomdom

C’est pour ça que si tu refais un test sans le certificat client et en mettant le nom d’hôte de ton serveur mqtt au lieu de l’adresse ip, il ne devrait pas y avoir de problème avec le port 8883

Désolé, mais toujours NON, cela ne marche pas :

De plus, dans cette configuration (sans certificat client - i.e. non coché) j’ai testé les 3 cas de figure avec chacune des options du popup « vérifier le certificat ». AUCUNE ne fonctionne. Pas de connexion.

[tomdom]

Et dans ce cas là les logs disent quoi ?

[tomdom]

J’ai trouver une potentielle erreur

J’ai copier/coller un certificat, à partir d’un éditeur de texte, dans les cases du plugin et j’ai été voir en base comment c’était rendu. Ben il y a des \n qui sont introduit à chaque fois que tu vois une ligne dans la case certificat du plugin. Donc les certificats sont considérés invalides.

Il faut essayer de mettre ce qu’il y a entre --BEGIN et --END en une ligne (supprimer les sauts de ligne à la main après avoir fait la copie)

Édit :
OK

-----BEGIN CERTIFICATE-----
MIIEYjCCAsqgAwIBAgIJAJm2YulYpr+6MA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNVBAYTAlhZMRcwFQYDVQQHDA5DYXN0bGUgQW50aHJheDEjMCEGA1UECgwaUHl0aG9uIFNvZnR3YXJlIEZvdW5kYXRpb24xFTATBgNVBAMMDGZha2Vob3N0bmFtZTAeFw0xODA4MjkxNDIzMTZaFw0yODA4MjYxNDIzMTZaMGIxCzAJBgNVBAYTAlhZMRcwFQYDVQQHDA5DYXN0bGUgQW50aHJheDEjMCEGA1UECgwaUHl0aG9uIFNvZnR3YXJlIEZvdW5kYXRpb24xFTATBgNVBAMMDGZha2Vob3N0bmFtZTCCAaIwDQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBAMqOuNZmV86zUKGq3VGjIt+rJdsdVcgBbR9PMDF8mfG8U6JaoAAqALapVAzxjTzSRFS5Fpc//D3LBdP4zNfq0HLLlVtNgljJOMc4fjoRYs11yoQmzj4UJWo4hitA9DqkYCEJeaAHLhVvjYkAEvBv4q37LYOTXm2CBVwAc/YqGuL6VFda91r6RkB7YXUiiOa5bIJPLcURgeJzmo0Gxdx/q7WjIVXwzJs67PXMaPe93YL50Qo7g6HD2tHCe8dJq2Mz4J/CJd/yRNfMMEVn/xbf7rIDj2kfFFsbsUTcrVMA+GSun4FVMhQ5x0jvjAQDpQSRYUXmxByaYC2Hn0wRCuXYJeit+0Q+GwpkTn11Q/X6dgA+9H+ZPJI0JLDv+u91/5yxFJnmiWUy7+XGyG26UlgkjTf4iINOfjsUjkP4gXblEQrt3gvMYijpPveS2xP6qlJce5NYL4gAGbwAwX3uWPEdLAxFT/P47m6I41Ei0MCAof84i0Ubng+1ja8CFo7RiJmtlwIDAQABoxswGTAXBgNVHREEEDAOggxmYWtlaG9zdG5hbWUwDQYJKoZIhvcNAQELBQADggGBAMIVLp6e6saH2NQSg8iFg8Ewg/K/etI++jHogCJ697AY02wtfrBox1XtljlmI2xpJtVAYZWHhrNqwrEG43aB7YEV6RqTcG6QUVqaNbD8iNCnMKm7fP89hZizmqA1l4aHnieI3ucOqpgooM7FQwLX6qk+rSue6lD5N/5favsublnj8rNKyDfHpQ3AWduLoj8QqctpzI3CqoDZNLNzaDnzVWpxT1SKDQ88q7VIW5zb+lndpdQlCu3v5HM4w5UpwL/k1htl/z6PnPseS2UdlXv6A8KITnCLg5PLP4tz2oTAg9gjOtRP/0uwkhvicwoFzFJNVT813lzTLE1jlobMPiZhsS1mjaJGPD9GQZDKny3j8ogrIRGjnI4xpOMNNDVphcvwtV8fRbvURSHCj9Y4kCLpD5ODuoyEyLYicJIvGZP456GP0iSCK5GKO0ij/YzGCkPWD5zA+mYFpMMGZPTwajenMw7TVaPXcc9CZBtroOjwwiLEqdkpxUj13mJYTlt5wsS/Kw==
-----END CERTIFICATE-----

KO

-----BEGIN CERTIFICATE-----
MIIEYjCCAsqgAwIBAgIJAJm2YulYpr+6MA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNV
BAYTAlhZMRcwFQYDVQQHDA5DYXN0bGUgQW50aHJheDEjMCEGA1UECgwaUHl0aG9u
IFNvZnR3YXJlIEZvdW5kYXRpb24xFTATBgNVBAMMDGZha2Vob3N0bmFtZTAeFw0x
ODA4MjkxNDIzMTZaFw0yODA4MjYxNDIzMTZaMGIxCzAJBgNVBAYTAlhZMRcwFQYD
VQQHDA5DYXN0bGUgQW50aHJheDEjMCEGA1UECgwaUHl0aG9uIFNvZnR3YXJlIEZv
dW5kYXRpb24xFTATBgNVBAMMDGZha2Vob3N0bmFtZTCCAaIwDQYJKoZIhvcNAQEB
BQADggGPADCCAYoCggGBAMqOuNZmV86zUKGq3VGjIt+rJdsdVcgBbR9PMDF8mfG8
U6JaoAAqALapVAzxjTzSRFS5Fpc//D3LBdP4zNfq0HLLlVtNgljJOMc4fjoRYs11
yoQmzj4UJWo4hitA9DqkYCEJeaAHLhVvjYkAEvBv4q37LYOTXm2CBVwAc/YqGuL6
VFda91r6RkB7YXUiiOa5bIJPLcURgeJzmo0Gxdx/q7WjIVXwzJs67PXMaPe93YL5
0Qo7g6HD2tHCe8dJq2Mz4J/CJd/yRNfMMEVn/xbf7rIDj2kfFFsbsUTcrVMA+GSu
n4FVMhQ5x0jvjAQDpQSRYUXmxByaYC2Hn0wRCuXYJeit+0Q+GwpkTn11Q/X6dgA+
9H+ZPJI0JLDv+u91/5yxFJnmiWUy7+XGyG26UlgkjTf4iINOfjsUjkP4gXblEQrt
3gvMYijpPveS2xP6qlJce5NYL4gAGbwAwX3uWPEdLAxFT/P47m6I41Ei0MCAof84
i0Ubng+1ja8CFo7RiJmtlwIDAQABoxswGTAXBgNVHREEEDAOggxmYWtlaG9zdG5h
bWUwDQYJKoZIhvcNAQELBQADggGBAMIVLp6e6saH2NQSg8iFg8Ewg/K/etI++jHo
gCJ697AY02wtfrBox1XtljlmI2xpJtVAYZWHhrNqwrEG43aB7YEV6RqTcG6QUVqa
NbD8iNCnMKm7fP89hZizmqA1l4aHnieI3ucOqpgooM7FQwLX6qk+rSue6lD5N/5f
avsublnj8rNKyDfHpQ3AWduLoj8QqctpzI3CqoDZNLNzaDnzVWpxT1SKDQ88q7VI
W5zb+lndpdQlCu3v5HM4w5UpwL/k1htl/z6PnPseS2UdlXv6A8KITnCLg5PLP4tz
2oTAg9gjOtRP/0uwkhvicwoFzFJNVT813lzTLE1jlobMPiZhsS1mjaJGPD9GQZDK
ny3j8ogrIRGjnI4xpOMNNDVphcvwtV8fRbvURSHCj9Y4kCLpD5ODuoyEyLYicJIv
GZP456GP0iSCK5GKO0ij/YzGCkPWD5zA+mYFpMMGZPTwajenMw7TVaPXcc9CZBtr
oOjwwiLEqdkpxUj13mJYTlt5wsS/Kw==
-----END CERTIFICATE-----

[oracle7]

@tomdom
Bon j’ai fait comme tu l’as préconisé, supprimé à la main tous les « fin de ligne » entre BEGIN et END.
J’ai procédé de deux façons : un coup directement dans le plugin, puis un autre coup avec édition préalable dans « UltraEdit » et C/C dans le plugin.

Désolé mais cela ne marche pas mieux dans les deux cas.

De toutes façons, si je peux me permettre, tu ne peux pas demander aux utilisateurs de procéder ainsi pour saisir leur certificats. C’est trop sources d’erreurs à mon humble avis et de surcroît difficile à débugger en suite pour savoir que cela viendrait de là.

Comme je le suggérais précédemment, il serait plus judicieux et bien plus simple, enfin je le crois, que l’utilisateur désigne simplement le fichier certificat (CA, client et key privée) après une recherche dans l’explorateur de fichiers ET qu’en suite ce soit le plugin qui fasse (si besoin en est effectivement) « le ménage » dans les « fins de lignes » de façon transparente. Maintenant ce n’est qu’une proposition d’évolution … A voir avec Domochip ce qu’il en pense si la solution est bien là …

[tomdom]

Faire déjà juste le test avec l’ac (sans mettre de certificat client) et en mettant le log du « ça marche pas », permettrait peut-être d’avancer, autrement tu peux attendre que le développeur fasse évoluer le plugin.

Bonne soirée

[oracle7]

@tomdom
J’ai donc fait le test avec uniquement le certificat AC et décoché le certificat client.

Toujours pareil cela ne marche pas : pas de connexion.

Le LOG jMQTTd :

[2022-12-19 22:47:33,982]DEBUG JMsg.Snd        SockOut           _loopSnd() : Sending 1 msgs
[2022-12-19 22:47:33,988]INFO Main            MainThread     h_delClient() : Starting removal of Client for Broker 466
[2022-12-19 22:47:33,989]DEBUG Client466       MainThread            stop() : jMqttClient ended
[2022-12-19 22:47:34,005]DEBUG JMsg.Snd        SockOut               send() : Sent TO Jeedom: [{'cmd': 'hb'}]
[2022-12-19 22:47:34,090]INFO Main            MainThread     h_newClient() : Creating Client for Broker 466.
[2022-12-19 22:47:34,092]ERROR Client466       MainThread           start() : Fatal TLS Certificate import Exception, this connection will most likely fail!
Traceback (most recent call last):
File "/var/www/html/plugins/jMQTT/resources/jmqttd/jMqttClient.py", line 218, in start
self.mqttclient.tls_set(ca_certs=certs, cert_reqs=reqs, certfile=cert, keyfile=key)
File "/var/www/html/plugins/jMQTT/resources/jmqttd/venv/lib/python3.7/site-packages/paho/mqtt/client.py", line 804, in tls_set
context.load_verify_locations(ca_certs)
ssl.SSLError: [X509] no certificate or crl found (_ssl.c:4053)
[2022-12-19 22:47:34,096]DEBUG JMsg.Snd        Brk466Th        send_async() : Enqued message: {'cmd': 'brokerDown', 'id': '466'}
[2022-12-19 22:47:34,096]ERROR Client466       Brk466Th     on_disconnect() : Unexpected disconnection from broker!
[2022-12-19 22:47:34,106]DEBUG JMsg.Snd        SockOut           _loopSnd() : Sending 1 msgs
[2022-12-19 22:47:34,184]DEBUG JMsg.Snd        SockOut               send() : Sent TO Jeedom: [{'cmd': 'brokerDown', 'id': '466'}]
[2022-12-19 22:47:36,099]INFO Main            MainThread     h_newClient() : Client already exists for Broker 466. Restarting it.
[2022-12-19 22:47:37,100]DEBUG Client466       MainThread            stop() : jMqttClient ended
[2022-12-19 22:47:37,102]ERROR Client466       MainThread           start() : Fatal TLS Certificate import Exception, this connection will most likely fail!
Traceback (most recent call last):
File "/var/www/html/plugins/jMQTT/resources/jmqttd/jMqttClient.py", line 218, in start
self.mqttclient.tls_set(ca_certs=certs, cert_reqs=reqs, certfile=cert, keyfile=key)
File "/var/www/html/plugins/jMQTT/resources/jmqttd/venv/lib/python3.7/site-packages/paho/mqtt/client.py", line 804, in tls_set
context.load_verify_locations(ca_certs)
ssl.SSLError: [X509] no certificate or crl found (_ssl.c:4053)
[2022-12-19 22:47:37,105]DEBUG JMsg.Snd        Brk466Th        send_async() : Enqued message: {'cmd': 'brokerDown', 'id': '466'}
[2022-12-19 22:47:37,106]ERROR Client466       Brk466Th     on_disconnect() : Unexpected disconnection from broker!
[2022-12-19 22:47:37,190]DEBUG JMsg.Snd        SockOut           _loopSnd() : Sending 1 msgs
[2022-12-19 22:47:37,261]DEBUG JMsg.Snd        SockOut               send() : Sent TO Jeedom: [{'cmd': 'brokerDown', 'id': '466'}]
[2022-12-19 22:47:42,110]DEBUG JMsg.Snd        Brk466Th        send_async() : Enqued message: {'cmd': 'brokerDown', 'id': '466'}
[2022-12-19 22:47:42,111]ERROR Client466       Brk466Th     on_disconnect() : Unexpected disconnection from broker!
[2022-12-19 22:47:42,172]DEBUG JMsg.Snd        SockOut           _loopSnd() : Sending 1 msgs
[2022-12-19 22:47:42,285]DEBUG JMsg.Snd        SockOut               send() : Sent TO Jeedom: [{'cmd': 'brokerDown', 'id': '466'}]
[2022-12-19 22:47:52,116]DEBUG JMsg.Snd        Brk466Th        send_async() : Enqued message: {'cmd': 'brokerDown', 'id': '466'}
[2022-12-19 22:47:52,116]ERROR Client466       Brk466Th     on_disconnect() : Unexpected disconnection from broker!
[2022-12-19 22:47:52,202]DEBUG JMsg.Snd        SockOut           _loopSnd() : Sending 1 msgs
[2022-12-19 22:47:52,265]DEBUG JMsg.Snd        SockOut               send() : Sent TO Jeedom: [{'cmd': 'brokerDown', 'id': '466'}]
[2022-12-19 22:48:03,754]INFO Main            MainThread     h_newClient() : Client already exists for Broker 466. Restarting it.
[2022-12-19 22:48:04,129]DEBUG Client466       MainThread            stop() : jMqttClient ended
[2022-12-19 22:48:04,132]ERROR Client466       MainThread           start() : Fatal TLS Certificate import Exception, this connection will most likely fail!
Traceback (most recent call last):
File "/var/www/html/plugins/jMQTT/resources/jmqttd/jMqttClient.py", line 218, in start
self.mqttclient.tls_set(ca_certs=certs, cert_reqs=reqs, certfile=cert, keyfile=key)
File "/var/www/html/plugins/jMQTT/resources/jmqttd/venv/lib/python3.7/site-packages/paho/mqtt/client.py", line 804, in tls_set
context.load_verify_locations(ca_certs)
ssl.SSLError: [X509] no certificate or crl found (_ssl.c:4053)
[2022-12-19 22:48:04,137]DEBUG JMsg.Snd        Brk466Th        send_async() : Enqued message: {'cmd': 'brokerDown', 'id': '466'}
[2022-12-19 22:48:04,138]ERROR Client466       Brk466Th     on_disconnect() : Unexpected disconnection from broker!
[2022-12-19 22:48:04,190]DEBUG JMsg.Snd        SockOut           _loopSnd() : Sending 1 msgs
[2022-12-19 22:48:04,268]DEBUG JMsg.Snd        SockOut               send() : Sent TO Jeedom: [{'cmd': 'brokerDown', 'id': '466'}]

Bonne soirée aussi, A+

[tomdom]

Bonjour,

@oracle7

File "/var/www/html/plugins/jMQTT/resources/jmqttd/venv/lib/python3.7/site-packages/paho/mqtt/client.py", line 804, in tls_set
context.load_verify_locations(ca_certs)
ssl.SSLError: [X509] no certificate or crl found (_ssl.c:4053)

Il n’arrive pas à lire le certificat de l’AC, il est possible qu’il reste des \n.

Tu peux le vérifier en allant dans Réglages/System/OS DB/Administration Base de donnée et tu fais la requête suivante, en mettant dans la clause where le nom de l’équipement broker (entre " ")

Personnellement, même en mettant sur une ligne dans un éditeur de texte, je me suis retrouvé avec 3 \n après la copie

Je suis d’accord avec toi sur le fait que le développeur de ce très bon plugin devrait apporter une petite amélioration à ce sujet (au moins le nettoyage des \n et des \r entre les lignes ---BEGIN et --END)

[rennais35000]

Bonjour,
Je suis en silencieux (admiratif) vos échanges pour essayer de faire fonctionner. Si l’un de vous 2 ou en coopération vous pouvez lorsque cela marchera faire un tuto compréhensif pour les nuls comme moi ce serait bien sympa
Bien cordialement

[freeddoo]

Bonjour à tous,

Également admirateur silencieux avec la même demande que rennais35000.

Bon travail à vous et bonne fêtes de fin d’année.

[Bad]

Bonjour à tous,
Je constate en effet un souci moi aussi en mqtts, je suis en train d’instrumentaliser le code pour en savoir plus.
Mais ce n’est probablement pas lié aux \n (ou \r), ils sont supportés par la lib SSL.
Bad

[Bad]

Alors il y a un plomb dans l’envoi de la clé privée du certificat client au démon…

L’erreur est ici :

Domochip/jMQTT/blob/7370804563d1f80f3067f7c226e6ef91e2ac17cc/core/class/jMQTT.class.php#L1853

Il suffit donc de remplacer :
if ($params['tlsclicert'] == '' || $params['tlsclikey'] = '') {
par
if ($params['tlsclicert'] == '' || $params['tlsclikey'] == '') {
dans core/class/jMQTT.class.php…

@oracle7, peux-tu check si ça corrige le problème pour toi stp ?

Avec toutes mes excuses

EDIT : Suite aux suggestions de @oracle7, il sera prochainement possible d’uploder les certificats :

Et de les drag & drop :

(dispo en stable depuis le 24/12/2022)

[tomdom]

Bonjour,

Désolé pour la mauvaise piste (\n). Par contre il a aussi un souci en mettant juste une ac privée (param tlsca). La bibliothèque paho ne trouve pas le certificat.

@oracle7

File "/var/www/html/plugins/jMQTT/resources/jmqttd/venv/lib/python3.7/site-packages/paho/mqtt/client.py", line 804, in tls_set
context.load_verify_locations(ca_certs)
ssl.SSLError: [X509] no certificate or crl found (_ssl.c:4053)

[oracle7]

@tomdom
Bonjour,
ATTENTION, pour moi il y aurait en fait deux types d’erreurs dans notre affaire qui se recoupent en partie. Mais je peux me tromper …
Je m’explique :

Point 1 :

@tomdom

Il n’arrive pas à lire le certificat de l’AC, il est possible qu’il reste des \n.

Je te confirme ce constat. De plus, il semblerait aussi qu’après le C/C du certificat CA (épuré sous éditeur de texte externe) dans le plugin, si le certificat comporte de caractères slash « / » tout court, ces caractères soient abusivement interprétés comme des « fin de ligne » « /n » lors du Coller et provoquent un retour à la ligne dans la zone du plugin lors de l’affichage. Cà ce n’est pas normal !!! Il y a sûrement un autre problème avec l’UI Jeedom à ce niveau. Ton avis STP ?
Attention toute fois, si on essaie de supprimer manuellement ce pseudo « fin de ligne » existant dans le plugin, cela supprime en fait le caractère « / », ce qui à mon sens dénature/modifie le certificat. Dans tous les cas, même si on ne supprime pas ces derniers, le certificat n’est tout de même pas reconnu valide et la connexion sécurisée ne s’établie pas. C’est mon constat.

Point 2:
J’ai donc exécuté la reqête SQL comme demandé.

1 - J’ai extrait du résultat la partie de chaine correspondante au certificat CA (-----BEGIN CERTIFICATE-----xxxxxxxxxxxxxxxxxxxxxxxxx-----END CERTIFICATE-----) → Chaine 1.
2 - J’ai ensuite épuré le certificat CA de ses « /n » pour le ramener sur une seule ligne → Chaine 2

3 - J’ai comparé ensuite avec « UltraCompare » les deux chaines 1 et 2.
Voici un extrait des différences constatées :
Chaine 1 :

DVqWH\/k7hLTDGSFNJ1PO2KgNpU7U06ujaio478xiDBErljcl0GnNMmUn6mIOgNgAdbxac\/2dbPlCH8

Chaine 2 :

DVqWH/k7hLTDGSFNJ1PO2KgNpU7U06ujaio478xiDBErljcl0GnNMmUn6mIOgNgAdbxac/2dbPlCH8

Dans la partie droite, apparaissent en rouge (les différences) les anti slash "" présents en plus dans le résultat de la requête SQL.

On constate donc que dans la Chaine 1 tous les caractères slash « / » sont "échappés systématiquement avec un caractère "" anti slash, donc qui vient en plus dans le certificat enregistré dans la BdD Jeedom.
C’est pareil pour le certificat client et sa clé privée présents dans le résultat de la requête SQL.

Dans la copie d’écran suivante on voit bien ces caratèresanti slash "" au début de chaque ligne dans le bloc résultat de requête SQL :

Voilà donc mes constats, en espérant que cela t’inspire …
PS : Au passage les caractères antislash ne sembles pas s’afficher au final dans le post. Ilsa s’affiche uniquement dans l’éditeur lors de la rédaction.

@rennais35000 @freeddoo
Au risque de vous décevoir tous les deux, je ne suis pas sûr que ce problème mérite un TUTO spécifique.
Vous l’aurez compris, on essaie ici de résoudre un disfonctionnement du plugin lié à la bonne prise en compte des certificats CA, Client et Clé privée client afin que la sécurisation des échanges MQTT soit parfaitement efficiente.
Si tout était bien, il n’y aurait juste qu’à renseigner l’UI du plugin avec les informations des certificats, c’est tout. Donc en soit la documentation du plugin me parait suffisante à ce niveau (même si elle est toujours perfectible ). Il n’y a rien de compliqué en soit.
Cordialement
oracle7

[oracle7]

@Bad @tomdom
Bonjour,

@Bad

@oracle7, peux-tu check si ça corrige le problème pour toi stp ?

J’ai donc corrigé le fichier en question comme indiqué (ajout signe =) et relancé le démon jQMTT.
Accessoirement, chez moi c’est la ligne 1848. Il me manquerait 5 lignes dans le fichier ???
BINGO !!! Le client jMQTT se connecte sur le port 8883 avec tous les certificats (C/C normalement sans supprimer les « /n »).
Le log jMQTTd :

[2022-12-20 14:12:30]INFO : Client MQTT déconnecté du Broker
[2022-12-20 14:12:30]INFO : Client MQTT déconnecté du Broker
[2022-12-20 14:12:34]INFO : Démarrage du Client MQTT
[2022-12-20 14:12:34]INFO : Client MQTT connecté au Broker
[2022-12-20 14:12:34]INFO : Souscription au topic d'Interaction 'jeedom/interact'
[2022-12-20 14:12:34]INFO : Le Broker Mosquitto_RPI-OUTILS s'inscrit au topic 'jeedom/interact' avec une Qos de 1
[2022-12-20 14:12:34]INFO : Le Broker Mosquitto_RPI-OUTILS s'inscrit au topic 'jeedom/interact/advanced' avec une Qos de 1
[2022-12-20 14:12:34]INFO : Souscription au topic API 'jeedom/api'
[2022-12-20 14:12:34]INFO : Le Broker Mosquitto_RPI-OUTILS s'inscrit au topic 'jeedom/api' avec une Qos de 1

ENORME MERCI à toi @Bad et merci aussi @tomdom pour sa patience avec tous mes « cela ne marche pas » à répétitions

Affaire résolue maintenant.
Y-a plus qu’à publier une mise à jour du plugin…