Problème de connexion MQTT via TLS auto-signé dans Home Assistant

Heliospeed · Février 4, 2026, 5:22

Bonjour,

Mon problème

Bonjour à tous,

J’ai un broker Mosquitto que je fais tourner dans Docker avec TLS auto-signé. Les certificats sont générés automatiquement par un script et renouvelés si nécessaire automatiquement.

Mon problème : je n’arrive pas à connecter Home Assistant à ce broker via l’UI (Configuration → Intégrations → MQTT). Les logs Mosquitto affichent :

OpenSSL Error while trying to get the error[0]: error:0A000418:SSL routines::tlsv1 alert unknown ca
Client 192.168.1.20 disconnected: Protocol error

Ma question : comment configurer correctement Home Assistant pour qu’il se connecte en TLS à un broker Mosquitto avec certificat auto-signé, et éventuellement ignorer la validation du certificat ?

Home Assistant refuse la connexion et je ne sais pas comment forcer TLS 1.2 ou ignorer la validation du certificat auto-signé.

Par exemple ma configuration pour Zigbee2mqtt qui fonctionne :

mqtt:
  server: tls://192.168.1.20:8883
  user: zigbee
  password: ***
  client_id: zigbee2mqtt
  reject_unauthorized: false
  base_topic: zigbee2mqtt
  keepalive: 60
  version: 4

Les autres clients fonctionnent aussi (jeedom, zwave, rflink, mqtt explorer, …)

Ma configuration

[center]## System Information

version	core-2026.1.3
installation_type	Home Assistant Container
dev	false
hassio	false
docker	true
container_arch	amd64
user	root
virtualenv	false
python_version	3.13.11
os_name	Linux
os_version	6.1.0-41-amd64
arch	x86_64
timezone	Europe/Paris
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
HACS Data	ok
GitHub API Calls Remaining	4996
Installed Version	2.0.5
Stage	running
Available Repositories	2680
Downloaded Repositories	1

Home Assistant Cloud

logged_in	false
can_reach_cert_server	failed to load: timeout
can_reach_cloud_auth	ok
can_reach_cloud	ok

Dashboards

dashboards	3
resources	0
views	1
mode	storage

Network Configuration

adapters	lo (disabled), ens18 (enabled, default, auto), br-26cd6bc63d21 (disabled), br-5749804e5a2d (disabled), br-6412030bc981 (disabled), br-8f0f167a7d95 (disabled), br-9c46a7a77a72 (disabled), br-a353d3c327c3 (disabled), br-b9b74d367e89 (disabled), br-22bf0f8de78b (disabled), docker0 (disabled), br-084d27ffedd9 (disabled), br-3c7ec7346620 (disabled), br-f2149703ad57 (disabled), br-3cc29ddc69ed (disabled), br-512a7132358a (disabled), br-b10065e211aa (disabled), br-4ce90f0cae57 (disabled), br-398baa372eb1 (disabled), br-b16978f500a2 (disabled), br-e4fb14252c37 (disabled), br-c1adce7c7411 (disabled), br-ce88d78843db (disabled), br-7fcb7cfa09fd (disabled), br-2d45a470c2df (disabled), br-ebbf2c8dba9d (disabled), br-19863fee6851 (disabled), br-cb8e09b1b782 (disabled), br-edd1fcd4a085 (disabled), veth08a24d2 (disabled), vethe17d6d7 (disabled), veth0f4256a (disabled), vethc9a1583 (disabled), veth74816a1 (disabled), vethc1ea63f (disabled), veth5bf2b49 (disabled), veth048b535 (disabled), veth477d616 (disabled), veth6ecc040 (disabled), veth86143fb (disabled), veth90d1b79 (disabled), veth2f8fb42 (disabled), veth3e1a4b8 (disabled), veth4e74640 (disabled), veth2f313bb (disabled), veth26e27c2 (disabled), vethb725268 (disabled), veth5e9675e (disabled), vethf53db79 (disabled), veth6efcad4 (disabled), vethfc9abc1 (disabled), veth213cb94 (disabled), vethd792023 (disabled), veth0df9db5 (disabled), veth48d892f (disabled)
ipv4_addresses	lo (127.0.0.1/8), ens18 (192.168.1.20/24), br-26cd6bc63d21 (192.168.32.1/20), br-5749804e5a2d (192.168.16.1/20), br-6412030bc981 (172.18.0.1/16), br-8f0f167a7d95 (172.21.0.1/16), br-9c46a7a77a72 (172.20.0.1/16), br-a353d3c327c3 (192.168.80.1/20), br-b9b74d367e89 (192.168.96.1/20), br-22bf0f8de78b (192.168.144.1/20), docker0 (172.17.0.1/16), br-084d27ffedd9 (192.168.64.1/20), br-3c7ec7346620 (192.168.112.1/20), br-f2149703ad57 (192.168.160.1/20), br-3cc29ddc69ed (192.168.128.1/20), br-512a7132358a (192.168.176.1/20), br-b10065e211aa (172.19.0.1/16), br-4ce90f0cae57 (172.22.0.1/16), br-398baa372eb1 (172.24.0.1/16), br-b16978f500a2 (172.25.0.1/16), br-e4fb14252c37 (172.26.0.1/16), br-c1adce7c7411 (172.27.0.1/16), br-ce88d78843db (172.28.0.1/16), br-7fcb7cfa09fd (172.29.0.1/16), br-2d45a470c2df (172.30.0.1/16), br-ebbf2c8dba9d (192.168.48.1/20), br-19863fee6851 (172.31.0.1/16), br-cb8e09b1b782 (172.23.0.1/16), br-edd1fcd4a085 (192.168.192.1/20), veth08a24d2 (), vethe17d6d7 (), veth0f4256a (), vethc9a1583 (), veth74816a1 (), vethc1ea63f (), veth5bf2b49 (), veth048b535 (), veth477d616 (), veth6ecc040 (), veth86143fb (), veth90d1b79 (), veth2f8fb42 (), veth3e1a4b8 (), veth4e74640 (), veth2f313bb (), veth26e27c2 (), vethb725268 (), veth5e9675e (), vethf53db79 (), veth6efcad4 (), vethfc9abc1 (), veth213cb94 (), vethd792023 (), veth0df9db5 (), veth48d892f ()
ipv6_addresses	lo (::1/128), ens18 (2a01:e0a:b28:b520:be24:11ff:fe2f:8e40/64, fe80::be24:11ff:fe2f:8e40/64), br-26cd6bc63d21 (fe80::2c21:dcff:fe17:bc3d/64), br-5749804e5a2d (fe80::b092:aeff:fee9:726d/64), br-6412030bc981 (fe80::6809:d6ff:fe21:78d8/64), br-8f0f167a7d95 (fe80::4436:a3ff:fe5a:4929/64), br-9c46a7a77a72 (fe80::28d8:c9ff:fe4a:c983/64), br-a353d3c327c3 (fe80::5c9c:c8ff:fef9:fe4/64), br-b9b74d367e89 (fe80::7cfa:a3ff:febd:e770/64), br-22bf0f8de78b (fe80::d4b1:a9ff:fee4:4bae/64), docker0 (fe80::c8f:abff:feb6:cdbd/64), br-084d27ffedd9 (fe80::bcf0:c2ff:fed7:51c6/64), br-3c7ec7346620 (fe80::6842:53ff:fe1e:d6c1/64), br-f2149703ad57 (fe80::94da:55ff:fe01:b278/64), br-3cc29ddc69ed (fe80::c456:2ff:fe9e:f838/64), br-512a7132358a (fe80::70e5:f9ff:fe0e:944/64), br-b10065e211aa (fe80::484b:e2ff:fedb:3fa7/64), br-4ce90f0cae57 (fe80::7cc4:10ff:feca:bc61/64), br-398baa372eb1 (fe80::e403:7bff:feb4:c29e/64), br-b16978f500a2 (fe80::d4f7:fdff:fe5b:be7/64), br-e4fb14252c37 (fe80::10a3:2fff:fe42:3b08/64), br-c1adce7c7411 (fe80::248b:71ff:fe0d:5770/64), br-ce88d78843db (fe80::e45d:39ff:fedc:cd9f/64), br-7fcb7cfa09fd (fe80::10b8:56ff:fe4d:b66c/64), br-2d45a470c2df (fe80::84be:70ff:fe7f:cc03/64), br-ebbf2c8dba9d (fe80::bc1d:77ff:fe67:3ddf/64), br-19863fee6851 (fe80::4e8:b0ff:fee6:7ab/64), br-cb8e09b1b782 (fe80::1887:5eff:fe94:abc0/64), br-edd1fcd4a085 (fe80::bce9:f5ff:fef9:5366/64), veth08a24d2 (fe80::a811:ccff:feaa:ce32/64), vethe17d6d7 (fe80::944f:f9ff:fee2:9bb0/64), veth0f4256a (fe80::5c6b:dbff:fe76:a9e4/64), vethc9a1583 (fe80::4ca:c4ff:fe5e:1a9c/64), veth74816a1 (fe80::309d:ceff:fe6a:5582/64), vethc1ea63f (fe80::a088:9eff:fecb:e5dc/64), veth5bf2b49 (fe80::68a4:29ff:fe78:c734/64), veth048b535 (fe80::54a8:12ff:fef1:4879/64), veth477d616 (fe80::4a1:ebff:fec3:4799/64), veth6ecc040 (fe80::248e:e2ff:fec6:aa46/64), veth86143fb (fe80::f40a:56ff:fef7:ff17/64), veth90d1b79 (fe80::fcc9:68ff:fe7a:5b35/64), veth2f8fb42 (fe80::8485:39ff:fe21:1a5c/64), veth3e1a4b8 (fe80::d881:b5ff:fe40:16f1/64), veth4e74640 (fe80::b0eb:9fff:fe33:b7d9/64), veth2f313bb (fe80::a898:16ff:fe32:2a30/64), veth26e27c2 (fe80::54f8:b5ff:fe55:1b1a/64), vethb725268 (fe80::387b:71ff:fe4f:ed5/64), veth5e9675e (fe80::5c7d:75ff:fe86:1b6c/64), vethf53db79 (fe80::2c96:64ff:fee3:f940/64), veth6efcad4 (fe80::2025:e7ff:fed1:d08f/64), vethfc9abc1 (fe80::ec94:eff:fe39:c6b9/64), veth213cb94 (fe80::1cf6:7eff:fedb:4ef3/64), vethd792023 (fe80::c56:c0ff:fefb:5101/64), veth0df9db5 (fe80::fc9b:3bff:fe65:cd31/64), veth48d892f (fe80::ec14:34ff:fe9d:1910/64)
announce_addresses	192.168.1.20, 2a01:e0a:b28:b520:be24:11ff:fe2f:8e40, fe80::be24:11ff:fe2f:8e40

Recorder

oldest_recorder_run	23 janvier 2026 à 22:37
current_recorder_run	4 février 2026 à 12:17
estimated_db_size	244.99 MiB
database_engine	sqlite
database_version	3.49.2

[/center] ___

ddfdom · Février 4, 2026, 5:32

Et pourquoi aller mettre des certificats sur mosquomitto est sur un lan ?
Supprimes plutôt tes certificats inutiles

Heliospeed · Février 4, 2026, 5:50

Je voulais sécuriser un peu le LAN afin d’éviter d’avoir trop de requêtes qui passent en clair (surtout via le Wi-Fi).

J’ai déjà créé des utilisateurs différents par client et ajouté une configuration ACL pour limiter l’accès aux topics.

Est-ce une mauvaise idée de sécuriser davantage en activant le TLS ?

J’ai plusieurs conteneurs qui communiquent via MQTT, puis Home Assistant et Jeedom qui s’y connectent et échangent entre eux via MQTT.

ddfdom · Février 4, 2026, 6:12

Ça n’a vraiment aucun intérêt si un hacker pénètre ton lan tu as bien plus de soucis à te faire ailleurs tu crains quoi sur ton mqtt ?que le mec récupère tes températures de salle de bain
Pour moi j’y vois aucun intérêt

Heliospeed · Février 4, 2026, 7:12

Je n’ai pas que des relevés de températures, je m’en sers aussi pour échanger des actions sur d’autres types d’appareils.
Après, il y a des périphériques type sirène, centrale d’alarme (Z-Wave par ex). Si cela remonte dans MQTT, j’y vois un risque.

Pulpy-Luke · Février 4, 2026, 7:21

Salut

Je plussoie la remarque de ddfom, si le lan est accessible, c’est que le souci est bien en amont ! Et c’est sans doute pas sur la domotique que l’intérêt du méchant vilain risque de se porter.

Toujours est-il que tu as proxmox, des containers et des VM…

Donc je ne pense que les périphériques qui font du direct en MQTT via le wifi sont pas les plus nombreux (ton Mosquitto, ton z2m sont dans proxmox) tu peux donc exploiter la notion de network dans les container docker, isoler les VLAN dans proxmox.

Et même ne l’écrivant, je me dis, mais quel boulot pour un truc improbable

ddfdom · Février 4, 2026, 7:26

Désolé mais c’est vraiment ridicule
Tu crois que le mec qui vas se faire chier a pénétrer ton réseau vas s’attaquer à ton mqtt pour désactiver ta sirène alors qu’il se trouve a sûrement plus de 20000 km de chez toi

Franchement comme @Pulpy-Luke plus j’en parle plus je trouve ça n’importe quoi

Quand tu vois que certains n’ont même pas de ssl sur leur accès distant HA

Heliospeed · Février 4, 2026, 7:52

Vous avez certainement raison sur le fait qu’un hacker n’a pas d’intérêt à distance de désactiver une sirène ou d’ouvrir les accès à un domicile.

Pourquoi un petit malin ne s’amuserait-il pas à pousser des OTA sur plein de périphériques histoire de les briquer, …

Un voleur ne pourrait-il pas accéder à une serrure connecté ? Imaginons un réseau wifi dans le domicile qui est actif au moment où l’on quitte son domicile. Il faut peu de temps pour trouver la clé et y accéder.

Après, je me prends la tête certainement pour pas grand-chose, mais je préfère sécurisé ça permet de prévenir, voir de ralentir des intrusions.

Après, ceux qui exposent des accès distants HA ou autre sont très joueurs. Perso, je ne le ferais pas.

Pour revenir au sujet initial de mon message si quelqu’un a une idée pour que le TLS fonctionne sans avoir a activer la validation du certificat, je suis preneur.
Sinon je serai obligé de passer un certificat client (et trouver une solution pour automatiser la Maj lors des renouvellements…)

ddfdom · Février 4, 2026, 8:06

Parce que tu coupes le wifi en sortant de chez toi ?
En attendant ton super hacker il en a rien a foutre de ta domotique si il veut rentrer chez toi il préférera une bonne hache

Tu as sûrement vu trop de films d’espionnage?

Sinon je ne me suis jamais intéressé aux certificats dans mqtt

Pulpy-Luke · Février 4, 2026, 8:19

Techniquement c’est sans doute possible qu’un petit malin à distance puisse faire ça, mais s’il le fait ce sera sans doute à cause d’une faille (genre ta caméra ou ton nas qui expose un service sur internet à ton insu, et il aura un script automatique qui prends tout ce qui permet d’exploiter cette faille) et surement pas quelqu’un qui spécifiquement campera devant chez toi, pour hacker.

Le méchant local a bien plus intérêt à faire dans l’efficace (la hache c’est pas si faux mais pas assez discret) pour prendre le moins de risque, et rester le moins longtemps possible. Plus tu traines plus tu te fais chopper.

Le premier qui risque de subir la sécurisation, c’est toi, parce qu’un jour le système que tu vas essayer de mettre en place ne fonctionnera pas (plus c’est compliqué, plus ça plante), donc ton MQTT ne marchera plus et tu arrivera chez toi avec une maison dont le chauffage est coupé depuis des jours…

Si tu veux ne prendre vraiment aucun risque, que du filaire, pas de zigbee non plus… et même ça, tu as toujours le souci d’un device un peu bavard

Heliospeed · Février 4, 2026, 9:03

Je ne coupe pas le Wi-Fi en sortant de chez moi. Dans les zones denses, comme les villes, on n’est jamais à l’abri qu’un petit malin essaie de bidouiller. J’imagine que vous ne laissez pas votre Wi-Fi sans mot de passe, même si techniquement cela ne ralentit que l’accès aux intrus.

À l’époque, seuls les sites des banques et des commerces étaient en HTTPS. Ce n’était pas utile pour les autres, mais c’est devenu la norme aujourd’hui.

Du coup, pour le MQTT, j’essaie de le sécuriser dès maintenant. J’y vais progressivement. Pour le moment, j’ai les deux accès MQTT et MQTTS en parallèle, et je bascule les clients au fur et à mesure.
Après je fais peut être cela pour rien, l’avenir me le dira .

Je cherchais juste une solution de by-passer la vérification du certificat pour aller plus vite. Mais je pense que je vais pas y échapper si home assistant ne sais pas faire.

ddfdom · Février 4, 2026, 9:12

Ton mqtt n’es pas exposé sur internet au pire il y’a 10 ans on avait des certificats auto signés qui chiffre tout de même la communication pour des besoins perso
Et le prix des certificats ssl n’es plus le même (merci let’s encrypt)
Mais encore aujourd’hui je n’ai pas de certificats ssl sur les services internes ton lan c’est une boîte étanche et bue sur si quelqu’un pénètre a l’intérieur autant te dire que ça bas devenir un carnage et que le mqtt vas être le cadet des tes soucis

Pulpy-Luke · Février 4, 2026, 9:13

Dans ton coin A*y/B*y l’ado de l’appart en dessous est potentiellement en mal de sensation forte, peut-être mais ça ne change rien que c’est surement pas la lumière du salon qui l’intéresse.
Et attention quand même, il y a une différence entre sur sécuriser et ne rien sécuriser du tout en laissant le mot de passe sans wifi (ou l’inverse)

ddfdom · Février 4, 2026, 9:17

Je dis souvent le trop est l’ennemie du bien

Pulpy-Luke · Février 4, 2026, 9:18

Et je le vérifie tous les jours au boulot