ich möchte gerne mit dem paho.mqtt.client per TLS auf den IPS MQTT Broker publishen. Ohne TLS ist es kein Problem.
Zur Umstellung auf TLS habe ich dann der IPS MQTT Server Socket Instanz dann ein von Let’s Encrypt signiertes Wildcard Certificate un den passenden Key verpasst und Use SSL aktiviert, nachdem ich den Port auf 8883 umgestellt habe.
Dem Webinterface Frontent Server habe ich das gleich Zertifikat usw. konfiguriert um zu checken, ob das mit dem Zertifikat denn zumindest per SSL Zugriff so klappt.
Mein Python Script habe ich entsprechend auf TLS angepasst. Wie ich verstanden habe, muss man bei Zugriff per paho mit TLS das zu erwartende Zertifikat der CA des Issuers meines Wildcard Zertifikates angeben. Und genau da hänge ich fest.
Nach meinem Verständnis ist das Issuer Zertifikat aktuell das Let’s Encrypt R3 Zertifikat. Ich habe es allerdings auch erfolglos mit dem DST Root CA X3 Zertifikat versucht. Die jeweils hinterlegten Zertifikate habe ich anhand der Seriennummern zuvor überprüft um sicher zu stellen, dass ich nicht versehentlich mit dem falschen Zertifikaten versuche.
Fehlermeldung: SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get issuer certificate (_ssl.c:1123)
Frage:
Hat von Euch schon jemand mit dem paho.mqtt.client erfolgreich Verbindungen zu dem IPS MQTT Broker aufgebaut und würde mir eventuell Hilfestellung geben?
Frage: IPS MQTT Broker - Zertifikats Kette für TLS??
Nun habe ich noch einige Tests mit anderen Clients gemacht z.B. mit dem Windows Client MQTTX. So konnte ich verschieden MQTT Broker mit TLS Verschlüsselung mit dem IPS MQTT Broker vergleichen.
Ich habe dem Server zuvor ein individuelles Zertifikat verpasst um Probleme mit dem zuvor verwendeten Wildcard Zertifikat auszuschließen.
Ergebnis ist, dass weder der MQTTX noch andere Clients die Zertifikatskette erfolgreich überprüfen können. Fehler: „Error: unable to verify the first certificate“.
Meine Recherchen haben ergeben, dass angeblich ein Konfigurationsfehler des Brokers vorliegen soll welches dadurch behoben werden kann, indem man das Intermediate Zertifikat der CA zusätzlich auf dem Server hinterlegen.
Bei der Webinteface WebFront Instanz kann man ein CA Zertifikat hinterlegen.
@paresy: Kann man das CA Zertifikat eventuell irgendwie auch für den MQTT Broker hinterlegen, dass ein Client die Zertifikatskette überprüfen kann?
Oder bin ich auf einer falschen Fährte?
Danke und viele Grüße
Dirk
.
.
.
Hier zur Certificate chain und einem Lösungsansatz aus einem Post, auch wenn es nur indirekt um eine Problemstellung wie bei mir geht. (Quelle)
Certificate chain
It most likely looks as follows:
Server certificate - stores a certificate signed by intermediate.
Intermediate certificate - stores a certificate signed by root.
Root certificate - stores a self-signed certificate.
Intermediate certificate should be installed on the server, along with the server certificate.
Root certificates are embedded into the software applications, browsers and operating systems.
The application serving the certificate has to send the complete chain, this means the server certificate itself and all the intermediates. The root certificate is supposed to be known by the client.
Du kannst das eine hochgeladene Zertifikat idr. so „zusammenkopieren“, dass du dein eigenen öffentlichen Teil sowie die CA Kette in EINER Datei hast. Diese speicherst du dann in Symcon.
danke für einen Hinweis. Hatte mich schon gefreut vielleicht eine Lösung gefunden zu haben. Ich habe mir mein Zertifikat entsprechend zusammen gebaut. Ich habe es auch mit einem Tool versucht, welches die Zertifikatskette anhand des eignen Zertifikat zusammenbaut. Die Zertifikatskette habe ich dann jeweils als mein Zertifikat über die IPS GUI für die Server Socket Instanz hochgeladen und die IPS dienste neu gestartet.
Leider alles erfolglos. Ich bekomme weiterhin immer die Meldung: „Error: unable to verify the first certificate“.
Ist es denn sicher, dass die von mir hochgeladene Zertifikatskette von IPS dann auch korrekt gehandhabt wird. Vielleicht kann IPS mit meiner Zertifikatskette nichts anfangen?
Außer mir werden sicher doch auch noch andere dem MQTT Broker mit TLS und Zertifikatskettenprüfung am Client verwenden?
Hast Du / Ihr noch weitere Ideen wo ich suchen könnte um das Problem zu lösen?
Ich muss mir dies mal genauer ansehen - es kann natürlich sein, dass wir hier noch etwas nicht ganz korrekt für deinen Anwendungsfall machen. Die SSL Anbindung im Server-Socket ist ja noch recht „frisch“.
Ich befürchte, dass wir hier noch ein Feld für die „Certificate Authority“ vergessen haben, welche wir auch beim WebServer anbieten, und worüber dann der Hostname auch geprüft wird.
Ich werde dies zur 5.6 hinzufügen und freue mich auf dein Feedback!
wegen der Zertifikatskette bin ich noch nicht final zum wirklichen Testen bekomme ;(. Ich hatte meine Zertifikate hoch geladen und mich zuerst auf TLS in Tasmota konzentriert.
Da benutze ich jetzt einen ESP32 mit Tasmota und TLS und übertrage die Werte von 2 Miflora Bluetooth Sendern. Auf dem dafür dedizierten MQTT Broker auf IPS laufen aktuell nur diese zwei Sensoren auf. Klappt auch.
Seit allerdings ca. 2-3 Wochen habe ich das Problem, dass der MQTT Broker die publizierten Werte nicht mehr “akzeptiert”.
Der ESP32 kann dann teilweise die Verbindung nicht mehr zum MQTT Server aufbauen. Teilweise sehe ich aber auch über Debug, dass die Daten vom ESP in IPS abgeliefert werden aber vom MQTT Broker nicht weiter verarbeitet.
Dann kam es schon vor, dass sich dann die Symcon Dienste nicht mehr stoppen ließen und ein Neustart des Raspberry’s ca. 10min gedauert hat.
Netzwerk Verbindungsprobleme habe ich ausgeschlossen.
ESP Probleme habe ich auch ausgeschlossen.
Gestern hatte ich wieder ein Hänger, der sich über Stunden nicht selber gelöst hat. Und das Problem konnte ich mit einem Restart von Symcon lösen.
Die anderen MQTT Broker, die keine TLS verwenden, sind meines Erachtens jeweils nicht betroffen gewesen und haben ganz normal weiter gearbeitet, auch wenn der TLS MQTT Broker hängen geblieben ist.
However, kann alles nur Zufall sein oder eine ungünstige Konstellation. Aber vielleicht gibt es ja doch irgendwelche Zusammenhänge mit Änderungen, denn davor hatte es mehrere Wochen ohne Probleme mit dem TLS funktioniert.