MQTT-Bug with CA-Certificate #3425
Comments
|
@SybexX Danke für die schnelle Hilfe. Die Issues habe ich selbst gar nicht gefunden, sorry... Mein Server hat tatsächlich nur >= TLS1.3 akzeptiert. Nachdem ich dies auf TLS 1.2 umgestellt habe, ging es aber leider immernoch nicht. Der Issue wurde allerdings schon geschlossen. @LordGuilly wollte dies noch auf seinem alten Gerät nachsehen. |
|
@theo416 Ich persönlich nutze TLS nicht und habe es auch nicht ausprobiert, aber soweit ich weiß, sollten dafür folgende Einschränkungen gelten:
Möglicherweise gibt es noch weitere Einschränkungen, die mir aber nicht bekannt sind. |
|
@SybexX dann wird das wahrscheinlich mein Problem mit dem 4096 RSA-Schlüssel sein. Vielleicht würde der ESP hier auch an/über sein Hardwarelimit kommen. Kann das jemand bestätigen? |
|
@theo416 Ich habe mal in der konfig nachgeguckt "CONFIG_MBEDTLS_SSL_OUT_CONTENT_LEN=4096", daher sollten 4096 Bits eigentlich auch funktionieren? folgendes habe ich noch gefunden: |
|
@SybexX Oke interessant! Ich habe gerade die Pakete mithilfe von Wireshark mitgeschnitten, um zu sehen, ob die Pakete < 1024 Byte sind (MFLN-Thematik). Dabei ist mir aber etwas anderes aufgefallen.
Stellt sich also die Frage, wieso der ESP hier ein FIN-Flag sendet?! Ich werde nicht schlau daraus. |
|
Danke @SybexX und @theo416 fürs Untersuchen.
Das wäre auf jeden Fall sinnvoll, bedingt aber, dass wir es verstehen :) Der Buffer wurde vor 2 Jahren von @Slider0007 in b85e3b1#diff-6e8bbe681cd5657650e19160363d8373be48a263e692a7d15e075064e062c611R226 eingeführt. Mit der Migration zu ESP IDF 5.0.1 in 17ffd28#diff-6e8bbe681cd5657650e19160363d8373be48a263e692a7d15e075064e062c611R264 wurde er nur umbenannt. Wir können CONFIG_MQTT_BUFFER_SIZE testweise mal auf 4096 erhöhen. |
|
@caco3 Danke fürs Ändern der config. Sobald wir das Problem behoben haben, werde ich die Hover-Hilfe auf jeden Fall (versuchen) anzupassen. Ich habe gerade den Build Soweit ich das in der untenstehenden Codezeile sehen kann, überprüft der ESP den CN des Zertifikats gar nicht (was ein weiterer Grund für eine Verbindungsablehnung wäre). Ich weiß nicht, wie wir den Fehler weiter eingrenzen könnten. Eventuell beim MQTT-Verbindungsaufbau mehr DEBUG-Nachichten ausgeben, bis wohin der Code überhaupt kommt? |
|
zu skip_cert_common_name_check steht in der esp-idf: |
@caco3: Nur das Ändern der sdkconfig hilft leider nicht, um hier was anderes zu testen, solange der Code nicht angepasst wird. Der Code schlägt die config. Ich persönlich habe TLS nur mit RSA2048 getestet. 4096 bisher nicht, daher kann ich nicht sagen, ob das überhaupt der limitierende Faktor ist. Nur die ESP Fehlermeldung hilft hier weiter. Auf der Console müssten ebenfalls zusätzliche Diagnose (inkl. Reject Reason) ausgegeben werden. @theo416 Daher wäre es hilfreich, die den Consolen Log zu sehen. (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/error-codes.html)
@theo416: Wie/warum hast du gewandelt? Fileendung ist nicht wirklich relevant, nur Inhalt sollte Base64-ASCII-coded sein. Bitte prüfe, dass es am Ende eine Newline vorhanden ist. Auch wichtig: Only unencrypted and not password protected files are supported.
Normalerweise sollte die Verbindung deswegen nicht rejected werden. Außer du hast deinen Server sehr restritiv eingestellt. Ich weiß aber aus dem Stand nicht, ob dies überhaupt so konfiguriert werden könnte. Zwar nicht die sicherste Variante, aber dafür für den User einfacher zu handeln. |
|
@Slider0007 danke für deine Hilfe! Zu Ich krame mal meinen TTL-Konverter heraus und melde mich dann mit dem Console-Log wieder bei euch. |
Wenn es da ohne Haken funktioniert, dann funktioniert es auch mit deaktiviertem Check, da genau das mit dem Flag ausgeschaltet wird. Es kann natürlich alles konfigurierbar gemacht werden. Man sieht aber auch jetzt schon, dass das die Mehrheit mit den aktuellen Einstellmöglichkeiten nicht versteht ;-) Könnte aber prinzipiell konfigurierbar gemacht werden.
Das geht auch mit der Webconsole (Webinstaller) |
Das habe ich schon verstanden. Hier der Output des Console-Logs: Das sieht doch ganz interessant aus! |
|
Das ist interessant. Das sieht nach Fehlkonfiguration im ESP aus. Du kannst diesen Testbuild (https://github.com/jomjol/AI-on-the-edge-device/actions?query=branch%3AIncreased-CONFIG_MQTT_BUFFER_SIZE) testen und den Log posten. Ich habe da die entsprechenden Flags gesetzt und den Puffer wieder auf Originalgröße gesetzt. |
|
Das sieht sehr gut aus! Mit deinem neuen Testbuild Die Verbindung zum Broker steht! |
Super! Danke für euren Einsatz! Mir ist nicht klar, wieso das eine unsichere TSL-Verbindung bedingt, das Zertifikat ist doch gültig! Oder ist das wie bei selbst-signierten SSL-Zertifikaten? Ich habe mal einen PR dafür angelegt: #3427 |
|
Ich würde das so interpretieren, dass das Flag siehe Beschreibung hier: https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/kconfig.html#config-esp-tls-insecure und https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/kconfig.html#config-esp-tls-skip-server-cert-verify Es könnte sein, dass das zweite Flag Die Server Verifikation könnte der Vollständigkeit halber natürlich auch konfigurierbar gemacht werden, ist aber dann eine weitere Konfigurationshürde / Fallstrick. Es sollte von den betreuen Devs eben auch verstanden werden können, ansonsten tut man sich keinen Gefallen. Ich persönlich würde es so lassen, da die meisten Ihr Zerifikat sowieso selbst generieren und wissen wo es herkommt. Für den Fall, dass einer die Verbindung kaperen sollte, weiß dieser eben einen Zählerstand ;-) |
|
@Slider0007 @theo416 wie erstellt ihr die Zertifikate, bei mir will es leider nicht funktionieren^^ |
|
@SybexX Ich habe meine PKI so aufgebaut: Dazu hier aufklappenCA-Zertifikat erstellenPrivaten Schlüssel erzeugenPEM pass Phrase vergeben, merken und geheim halten! Sehr sehr wichtig Öffentlichen Schlüssel dazu erzeugenDaten ausfüllen (müssen nicht unbedingt alle sein) Server-Zertifikat erstellenPrivaten Schlüssel erzeugenConfig-File anlegenDiesen Weg habe ich gewählt, damit ich mehrere DNS-Adressen etc. angeben kann (mit und ohne Domain...) Certificate signing request anlegenZertifikat mit CA signierenZertifikat auf MQTT-Broker ladenDie Dateien Zertifikat in Config aktivieren@caco3 @Slider0007 Ich schließe mich da @Slider0007 im ersten Teil an. Hier ein kurzer Auszug aus ESP-IDF: Was halten die anderen Devs davon? Die Hover-Hilfe könnte ich dazu auch erstellen, wenn ihr mir kurz erklärt, wie :) |
|
Ja, ich denke, einen zusätzlichen Parameter dafür wäre sinnvoll. @theo416 Für den zusätzlichen Parameter musst Du
|
|
@theo416 Ich habe deine Änderungen(patch-1, patch-2, patch-3, patch-4) übernommen und alles, was noch nötig war, in einen Branch gepackt, es aber noch nicht getestet. |
|
@SybexX Danke fürs schnelle Ändern Ein paar Dinge sind mir noch aufgefallen:
|
|
https://github.com/jomjol/AI-on-the-edge-device/actions/runs/12480968919 Es ist ausgegraut, wenn der Parameter in der config.ini auskommentiert ist (unbenutzter Parameter) ";ValidateServerCert = true" |
|
Ich habe die letzte Firmware (Commit: 4d74d0c+) getestet. Die Konfigurationsseite lädt nicht mehr. Nur der oberste Teil erscheint. Der Rest ist weiß. Habe schon neu gestartet etc. In der config.ini ist der Parameter noch nicht eingetragen.
Auch das manuelle Hinzufügen + Reboot des Parameters brachte bei mir nichts. |
|
Aha, es hat sich etwas geändert:
Siehe Pfeil. |
|
Jetzt verbindet er sich erfolgreich mit dem MQTT-Broker, aber akzeptiert auch den Server mit dem "fake"-Zertifikat... |
|
Da beim Aktivieren der Überprüfung keine Verbindung zustande kommt, würde ich sagen, dass bei der Erstellung des Zertifikats etwas nicht stimmt bzw. der ESP etwas anderes erwartet oder es ein bug diesbezüglich in der esp-idf gibt. |
|
Wollt ihr das umsetzen? Ansonsten belassen wir es beim Alten. |
|
ich habe da noch was gefunden: in unserem Fall ist "If NULL, server certificate CN must match hostname." zutreffend, da common_name nirgends gesetzt wird. |
|
So sieht meine Konfigurationsdatei für das Server Zertifikat aus (Servername ist abgeändert). Der CN enthält nur eine Beschreibung des Servers. Wahrscheinlich prüft der ESP wirklich nur den CN und nicht die Alt-Names oder? Sämtliche MQTT TLS-Clients kommen mit dieser Konfiguration zurecht. Diese verbinden sich mithilfe des Hostname unter DNS.3 |
davon gehe ich auch aus und sämtliche Beispiele die ich im internet gefunden habe, hatten immer und dann findet ja überhaupt keine Überprüfung statt^^ |
|
Tut mir leid, dass ich das nicht schon früher erwähnt habe... Ich habe über das Thema nicht so richtig viel gefunden, nur diesen mbedtls Issue. Da ging es aber nur darum, dass in der Zertifikats-Konfiguration unter den alt_names Korrektur zu meiner Zertifikatskonfiguration: Ich habe gerade Aber dann werden/müssen wir es wohl bei der Verbindung ohne Überprüfung belassen. |
|
wenn ich es im esp-idf code richtig verfolgt habe, muß MQTT_ENABLE_SSL aktiviert werden um mqtt_cfg.broker.verification.skip_cert_common_name_check wirksam zu machen und es hat nichts mit CONFIG_ESP_TLS_SKIP_SERVER_CERT_VERIFY=y zu tun. CONFIG_ESP_TLS_SKIP_SERVER_CERT_VERIFY hat Auswirkung auf "esp_tls_cfg.common_name" |
|
Das bedeutet für uns jetzt folgendes? |
|
@theo416 ein neuer Versuch: https://github.com/jomjol/AI-on-the-edge-device/actions/runs/12944046286/artifacts/2479055357 Da ich bis jetzt irgendwie es immer noch nicht mit den Zertifikaten hinbekommen habe, auch nach deiner Anleitung funktioniert es leider nicht, kann ich die Änderungen nicht testen. Ich weiß nicht was da schief läuft, vieleicht liegt es auch am Iobroker selber, wer weiß^^ |
|
so ich habe jetzt einen test-broker auf mein linux pc erstellt und getestet, mein Resultat:
|
|
Das ist echt komisch... Soll ich deinen Run von obentrotzdem noch testen? |
|
@theo416 Ich habe jetzt den Fehler in der Firmware gefunden, jetzt muss ich nur noch einen Weg finden, ihn zu fixen.^^ |
|
@theo416 https://github.com/jomjol/AI-on-the-edge-device/actions/runs/12944046286/artifacts/2479055357 bereits von mir getestet:
jetzt fehlt noch:
Habe das Ca-Zertifikat immer nur beim ESP32 getauscht, geht schneller als es beim Broker zu machen^^ Ein Problem war mitunter, dass der Dateipfad nicht passte. Da hat immer "/sdcard" davor gefehlt(CACert = /config/certs/RootCA.crt mußte man auf CACert = /sdcard/config/certs/RootCA.crt ändern) und dadurch konnte kein Zertifikat geladen werden. Ich habe das jetzt nur provisorisch gefixt, indem ich beim lesen des Parameters "/sdcard" hinzufüge. Wenn ich zeit habe, wollte ich eine Überprüfung hinzufügen, damit man beide Varianten nutzen kann. |
|
Cool!
Alle anderen Pfadangaben in der config sind relative zu |
|
Ich habe einige interessante Informationen über alt_names gefunden: https://www.emqx.com/en/blog/emqx-server-ssl-tls-secure-connection-configuration-guide
|
|
@SybexX Perfekt. Dann teile ich hier mal meine weiteren Ergebnisse.
SSL-Verbindung:
Dabei ist Zur Zeile 3: Zu Zeile 9: Zu Zeile 13: Gib mir für die restlichen Einträge noch etwas Zeit. Ich muss es erst schaffen, ein abgelaufenes CA-Cert zu erstellen, sowie die Client-Zertifikate zu erstellen...
Genau das habe ich hier gemacht. Der Artikel ist dennoch schön übersichtlich! Danke dafür. |
ja schon, du hast aber auch die IPs unter DNS. eingetragen und ich weiß nicht ob es zum Fehler beim ESP führt bzw. ob sie dann vom ESP richtig berücksichtigt werden.
|
|
habe ich voll übersehen^^ |
|
@theo416 zu alt_name habe ich jetzt folgendes in der espidf gefunden: .platformio\packages\framework-espidf\components\mbedtls\mbedtls\library\x509.c (ab Zeile 1289) jedoch scheint eine IP als alt_name zu funktionieren(da dies im Code implementiert ist), vorausgesetzt der CN ist keine IP oder Domain. |
Weißt du von wo openssl das aktuelle Datum bezieht? Sonst könnte man doch probieren, das System-Datum vom PC um ein Jahr zurücksetzen und dann die Zertifikate mit einer kürzeren Laufzeit zu erstellen. |
Ja ,die System-Uhr wird verwendet. Das würde mittels Wenn ich heute Zeit und Lust finde, werde ich das noch umsetzen. Ansonsten habe ich gestern ein paar Zertifikate erstellt (CA + Server), die heute und morgen 22:00 Uhr ablaufen. |
|
So, habe nun sämtliche Varianten der oberen Tabelle mithilfe von Zusammenfassend lässt sich sagen:
|
|
@theo416 CONFIG_MBEDTLS_HAVE_TIME_DATE war nicht aktiviert, jetzt sollte es gehen. |
|
@SybexX Bei Konfiguration Zeile 7 + neuem Build mit aktiviertem EDIT: Moment, CA falsch geschrieben |
|
@SybexX So, jetzt siehts gut aus. Daraus ergibt sich eine neue Tabelle für den neuen Build:
Daraus ergibt sich folgende Prüfreihenfolge:
Schlägt einer dieser Schritte fehl, werden die nachfolgenden Schritte nicht mehr ausgeführt und die Verbindung abgelehnt. Alle meine Tests waren jetzt erfolgreich. Ist nurnoch die Frage, ob man abgelaufene Zertifikate von Haus aus ablehnt oder wieder einen Parameter einbaut. Normalerweise sollte man gar keine abgelaufenen Zertifikate zulassen können, oder? EDIT: Normale Verbindungen ohne TLS funktionieren weiterhin |
@theo416 Um dafür ein Parameter einzubauen, ist ein sehr großer Zeitaufwand nötig, da es seitens espidf dafür keiner vorgesehen ist. Daher würde ich sagen, belassen wir es erstmal dabei. @caco3 @jomjol was sagt ihr dazu? |
The Problem
Bei der Angabe eines CA-Zertifikats im PEM-Format und anschließendem Neustart scheiterte die Verbindung zum MQTT-Broker.
Das X.509 CA-Zertifikat wurde mit openssl erstellt und von
.crtin.pemumgewandelt, damit Konfiguration analog dem Konfigurationsbeispiel.Die PKI funktioniert im restlichen Netzwerk für MQTT etc. problemlos!
Das Zertifikat wird laut Log erkannt.
MQTT-Verbindung kommt aber nicht zustande.
Der MQTT-Broker ist für TLS konfiguriert und wird auch schon damit verwendet.
Version
15.7.0
open Logfile
Expected Behavior
Ich würde erwarten, dass der ESP mit dem konfigurierten Zertifikat den Server validiert und sich anschließend mit diesem verbindet.
Screenshots
No response
Additional Context
Untenstehend der Log-Auszug des mosquitto-Brokers. Dieser könnte interessant sein. Der erste Such-Match führte zu openssl #22690.
The text was updated successfully, but these errors were encountered: