MQTT et broker certificate validation

Bonjour,
Le contexte :
Je viens de migrer d’une configuration HA supervised à HA container sur un NUC sous Debian 11 et Docker et par ailleurs, mon serveur MQTT Mosquitto est un RPI3B.

J’essaie donc de configurer à nouveau mon intégration de MQTT dans HA container avec mes certificats SSL client et CA (personnelle).

Autant lorsque j’étais sous HA Supervised la configuration de MQTT s’était effectuée sans problèmes avec les mêmes certificats et l’activation de la « broker certicate validation », autant sous HA container impossible d’établir une connexion au serveur MQTT Mosquitto si je ne désactive/ignore pas le « broker certicate validation ».

Par alleurs, j’écarte tout problème de certificats car avec ces même certificats et la validation certificat, sous MQTT Explorer je me connecte sans problèmes :

Du coup, selon vous qu’est-ce que je rate ou n’ai pas fait dans HA qui puisse bloquer cette connexion au serveur MQTT Mosquitto ?
Je souhaite sécuriser au maximum cette connexion donc ne pas avoir à désactiver la validation du certificat.
EDIT : Une précision, sous MQTT explorer pour l’@ du serveur MQTT j’utilise le nom d’hôte (RPI-OUTILS) de la machine qui supporte ce serveur alors que sous HA impossible de saisir ce nom d’hôte je dois impérativement mettre l’@IP locale 192.168.2.52 de cette machine (RPI3B).
Merci de votre aide.
Cordialement
oracle7 :wink:

Le certificat c’est bon pour le nom (si le certificat est bien fait) mais jamais pour une @IP. Donc, forcer la validation du cert en rentrant une @IP ça ne peut pas marcher…

Je suis d’ailleurs surpris que ton certificat soit valide avec un nom de host RPI-OUTILS (sans domaine…)?
Je vois que tu as un CA propre. Mais, pour qu’il soit accepté par les différents morceaux de ton infra, il faut importer cette CA partout. C’est bien le cas?

Et comment HA Container pourrait résoudre le nom RPI-OUTILS?

Mettre des certificats sur son LAN, même pour de la communication locale, pourquoi pas. C’est (à mon avis) compliqué pour pas forcément grand chose, mais le faire avec sa propre autorité de certification, ça me parait très sport…

@golfvert

On est bien d’accord pour l’@IP, d’autant plus que d’alprès les bonnes pratiques que j’ai pu relevées en épluchant la toile, sont que le CommonName doit être un domaine pour le certificat CA et être le hostname de la machine hôte pour un certificat client ou serveur. En tous cas jamais le même CN pour le serveur et chaque client.
*** Quelques Références *** :
https://www.schaerens.ch/raspi-setting-up-mosquitto-mqtt-broker-on-raspberry-pi-docker/

Oui absoluement, de toutes façons, la CA est demandée systèmatiquement dès lors que l’on active l’option de validation du certificat.

Je te retourne la question : pourquoi ne le fait-il pas ? car HA Supervised le fait bien lui ! et ainsi la connexion s’établit sans problème. Les deux sont sous docker que je sache, non ? alors pourquoi cette dfférence de traitement ?

Aujourd’hui, oui car les senseurs (en phase test) sont « locaux » mais à terme ils seront distants. Les payload MQTT des senseurs remonteront au serveur MQTT (distant lui aussi) via une connexion qui devrait être en plus sous VPN. En clair, l’objectif est de piloter/contrôler la domotique d’un site distant. C’est ambitieux, je te l’accorde mais pour l’heure onfait comme si mais en local. De plus, il est bien connu que certains IoT sont de vrai passoires en terme de sécurité donc autant essayer de verrouiller les choses au maximum de ce point de vue. Mais ce n’est que mon avis…

Au final, je ne comprend toujours pas pourquoi ma connexion sous HA Container ne s’établit pas avec le contrôle de validation du certificat.

C’est toi qui sait comment ton infra est installée… Comment est connu le nom RPI-OUTILS? Qui fait le lien nom → IP ?

Avec HA Supervised, le container HA est installé en network « host », tu as fait pareil en container?
Dans un cas, nom → IP marche et pas dans l’autre. C’est ça qu’il faut traiter d’abord. Certificat et @IP c’est la misère…

Et vu que ton infra est assez compliquée, ça vaudrait le coup d’avoir ton domaine et des « vrais »
certificats. Avec traefik, let’s encrypt, un fournisseur de DNS avec une API qui va bien (gandi par exemple), ça me semblerait être des bases plus fiables.

Merci de m’avoir « mis la puce à l’oreille » sur ce point. effectivement à vouloir trop sécuriser les choses, j’avais installé HA Container avec un réseau bridge externe spécifique. Du coup en mode « host », ma connexion sécurisée au broker s’est établie du premier coup avec la validation du certificat et en mettant mon hostname (RPI-OUTILS) comme @ du broker.

A ce niveau en fait, j’avais déjà mis dans le fichier /etc/hosts de chacune de mes machines de mon réseau local une ligne avec la correspondance @IP - Hostname et ce pour toutes les machines du réseau local soit par exemple 192.168.2.52 RPI-OUTILS dans le cas de mon broker MQTT. Je ne saurais dire si cela joue aussi ou si c’est superflu. Ton avis STP ?

Sinon au final, tout est OK maintenant, HA container m’a même découvert en plus (rien de plus normal en somme) tout un tas d’autres périphériques que je vais pouvoir aussi intégrer.

Merci encore en tout cas de t’être pencher sur mon problème.
Cordialement
oracle7 :wink:

Si ça joue pour quoi? ou superflu par rapport à quoi?

Et je maintiens, des certificats sans FQDN (fully qualified domain name) et avec un CA maison, c’est chercher les ennuis :wink: