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 :) |
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
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: