Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Sven Schumacher]

Ich möchte gerne einen MQTT anbieten, der per TLS verschlüsselt kommuniziert.

Unverschlüsselt geht es problemlos. Von außen, aus dem lokalen Netz und local.
Mit TLS hatte ich auf keinem Weg Erfolg. So teste ich jetzt auf dem Server selbst zwei Instanzen:
mqtt.0 ist der Server
mqtt.1 ist der Client

Ich nutze vom Client die IP 127.0.0.1 um zum Server zu verbinden. Eine Firewall ist auf dem Rechner selbst nicht installiert.

Ohne TLS/SSL klappt die Verbindung umgehend und ich sehe die States von mqtt.0 in mqtt.1
Mit TLS zeigt der Client an, dass er verbunden ist, aber der Server weiß davon nicht. Der Client macht dann einen neuen Versuch sich zu verbinden. Allerdings ohne Erfolg.

SSL-Verbindungen zu Admin, Grafana, NodeRed und VIS sind fehlerfrei.

Ich sehe auch mit "Silly"-Einstellungen keine Einträge im Log im Admin.

Ich habe offizielle LetsEncrypt-Zertifikate benutzt, die für SSL wunderbar funktionieren.
Ich habe auch selbst signierte Zertifikate benutzt. Zum Test habe ich nicht nur moderne Zertifikate erstellt, sondern auch TLS 1.1 kompatible RSA-Zertifikate.

Hat schon mal jemand einen Server mit dem MQTT.Adapter erstellt, der z. B. mit MQTT-Explorer erreichbar war?
Wenn SSL hier aus irgendeinem Grund eben nicht geht; welchen Broker könnte ich noch einsetzen?

gibt es irgendwo andere logs?

Das hier sehe ich mit TCPDUMP

sudo tcpdump -i any host 192.168.240.105 and tcp port 8883
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
14:24:57.729311 ens192 In  IP 192.168.240.105.63647 > 192.168.240.100.8883: Flags [S], seq 3221089395, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
14:24:57.729332 ens192 Out IP 192.168.240.100.8883 > 192.168.240.105.63647: Flags [S.], seq 165142938, ack 3221089396, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:24:57.730863 ens192 In  IP 192.168.240.105.63647 > 192.168.240.100.8883: Flags [.], ack 1, win 1026, length 0
14:24:57.732400 ens192 In  IP 192.168.240.105.63647 > 192.168.240.100.8883: Flags [P.], seq 1:256, ack 1, win 1026, length 255
14:24:57.732410 ens192 Out IP 192.168.240.100.8883 > 192.168.240.105.63647: Flags [.], ack 256, win 501, length 0
14:24:57.733087 ens192 Out IP 192.168.240.100.8883 > 192.168.240.105.63647: Flags [P.], seq 1:1098, ack 256, win 501, length 1097
14:24:57.736429 ens192 In  IP 192.168.240.105.63647 > 192.168.240.100.8883: Flags [P.], seq 256:681, ack 1098, win 1022, length 425
14:24:57.737160 ens192 Out IP 192.168.240.100.8883 > 192.168.240.105.63647: Flags [P.], seq 1098:1672, ack 681, win 501, length 574
14:24:57.779762 ens192 In  IP 192.168.240.105.63647 > 192.168.240.100.8883: Flags [.], ack 1672, win 1026, length 0

Das log zeigt den Versuch einer Verbindung vom Laptop. Wenn ich eine Weile warte, dann kommt das gleiche immer wieder mit jeweils einem zufälligen Port im Hohen Bereich

[Marc Berg]

@sven-schumacher sagte in MQTT TLS Server:

Wenn SSL hier aus irgendeinem Grund eben nicht geht; welchen Broker könnte ich noch einsetzen?

Das Problem scheint bekannt (hier wird vergeblich versucht, sich mit dem Mosquitto Client am Broker mit SSL Verschlüsselung anzumelden):

https://github.com/ioBroker/ioBroker.mqtt/issues/341

Nimm doch einfach den Mosquitto als Broker.

[Sven Schumacher]

@marc-berg Dann natürlich ohne Integration in Admin ... Das ist weniger übersichtlich.
Deswegen hatte ich das nicht gleich schon versucht.

Vorteil ist, dass es keine states erzeugt. Das hilft bei der Performance.

Aber dann bleibt mir da wohl nichts übrig. Scheint auch niemanden dort zu interessieren, der bug.

[Sven Schumacher]

@sven-schumacher Und dann das Übliche:

Ich habe:

• alles gemacht, wozu ICH in der Lage bin, um den Fehler reproduzierbar zu machen.
• es so einfach gemacht, wie es geht, um alle möglichen fremden Fehlerquellen ausschließen zu können.
• es von mehreren Orten und Systemen getestet.
• es ausführlich auf GitHub beschrieben.

Aber auf GITHUB erwartet man, dass ich auch wireshark-Protokolle erstellen und auswerten soll. Das kann ich auf den Maschinen nicht und ich kann die Ergebnisse auch nicht wirklich lesen und verstehen.

Aber dort ist man der Meinung, ich müsse mir mehr Mühe geben.

Nein! Ich bin letztlich User, nicht DevOp. Genau an der Stelle scheitern viele Linuxprojekte für Anwender, weil hier Hürden entstehen, die unüberwindbar sind.

Dann bleibt der Fehler eben bestehen. Mit Mosquitto geht jetzt (fast) alles.
Ich hab’ nur noch Fragen zu QOS … aber das ist etwas anderes. SSL/TLS geht, und zwar mit genau den Certs und mit genau den Einstellungen, die bei dem Adapter nicht funktioniert haben.