Von English mit KI übersetzt ·
Student hier, erster Beitrag. Ich baue für ein Laborprojekt einen Bodenfeuchte-Logger: Pi 3, kapazitiver Sensor über einen ADS1115, paho-mqtt 1.6, Senden an Hermetry auf 8883. Im heimischen WLAN funktioniert alles. Im Labor schlägt es jedes Mal fehl:
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: certificate is not yet valid (_ssl.c:1006)Das Labornetz blockiert viele Dinge, deshalb habe ich auch versucht, mich über die IP-Adresse des Brokers statt des Hostnamens zu verbinden (ich hatte sie zu Hause aufgelöst und fest eingetragen), und dann ändert sich der Fehler zu einer Abweichung des Hostnamens. Ich habe certifi neu installiert und client.tls_set() mit und ohne den ca_certs-Pfad aufgerufen. Nichts hilft. Ist es die Labor-Firewall, die TLS stört?
Student here, first post. I’m doing a soil moisture logger for a lab project: Pi 3, capacitive sensor via an ADS1115, paho-mqtt 1.6, sending to Hermetry on 8883. On my home Wi-Fi everything works. In the lab it fails every time:
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: certificate is not yet valid (_ssl.c:1006)The lab network blocks a lot of things, so I also tried connecting to the broker’s IP instead of the host name (I resolved it at home and hardcoded it) and then the error changes to a hostname mismatch. I’ve reinstalled certifi and called client.tls_set() with and without the ca_certs path. Nothing helps. Is it the lab firewall messing with TLS?
Von English mit KI übersetzt ·
Ist 8883 in diesem Netzwerk überhaupt offen? Manche Standorte erlauben ausgehend nur 80 und 443.
Is 8883 even open on that network? Some places only allow 80 and 443 out.
Von English mit KI übersetzt ·
Er muss offen sein, der Handshake startet, er scheitert nur am Zertifikat.
It must be open, the handshake starts, it just fails on the certificate.
Von English mit KI übersetzt ·
Vielleicht brauchen Sie ein Client-Zertifikat für den Broker? Wir mussten auf unseren Linien-PCs eines laden.
Maybe you need a client certificate for the broker? We had to load one on our line PCs.
Von English mit KI übersetzt ·
Was zeigt date auf dem Pi an, wenn du im Labor bist?
What does date say on the Pi when you’re in the lab?
Von English mit KI übersetzt ·
…dort steht März des letzten Jahres. Zu Hause stimmt es.
…it says March of last year. At home it’s right.
Von English mit KI übersetzt ·
Dann ist es das. Ein Pi 3 hat keine echte Echtzeituhr. Beim Booten stellt er die Zeit wieder her, die er beim letzten sauberen Herunterfahren gespeichert hat (fake-hwclock), und wartet dann auf NTP. Dein Lab-Netzwerk blockiert NTP (UDP 123), also bleibt die Uhr in der Vergangenheit, und für die TLS-Bibliothek ist das Serverzertifikat noch nicht gültig. Das habe ich bei der Inbetriebnahme schon auf der Hälfte der Feld-Pis hinter abgeschotteten Firewalls gesehen.Lösungen, wähle eine:
# 1. die interne NTP-Adresse bei der IT erfragen und verwenden
sudo nano /etc/systemd/timesyncd.conf
[Time]
NTP=ntp.your-lab.example
sudo systemctl restart systemd-timesyncd
timedatectl # "System clock synchronized: yes"
# 2. falls nur 443 offen ist: Synchronisation über HTTPS-Header
sudo apt install htpdate
sudo htpdate -s https://www.example.orgDie fest eingetragene IP entfernen. Der Broker benötigt SNI, also über den Hostnamen verbinden; das Zertifikat wird ohnehin gegen diesen Namen geprüft, deshalb kam die Abweichung zustande. Einfaches client.tls_set() mit dem System-CA-Bundle reicht aus; Tyler, für Token-Logins wird kein Client-Zertifikat benötigt, der Server fordert eines an, verlangt es aber nicht.Außerdem sollte das Skript vor dem Verbinden auf eine synchronisierte Uhr warten, sonst bricht ein Neustart im Lab die Verbindung erneut ab. Eine kurze Schleife über timedatectl show -p NTPSynchronized funktioniert. Siehe den TLS-Abschnitt von MQTT.
That’s it then. A Pi 3 has no real time clock. At boot it restores the time it saved at the last clean shutdown (fake-hwclock) and then waits for NTP. Your lab network blocks NTP (UDP 123), so the clock stays in the past, and to the TLS library the server certificate isn’t valid yet. Seen this on half the field Pis I’ve commissioned behind locked-down firewalls.
Fixes, pick one:
# 1. ask IT for the internal NTP server and use it
sudo nano /etc/systemd/timesyncd.conf
[Time]
NTP=ntp.your-lab.example
sudo systemctl restart systemd-timesyncd
timedatectl # "System clock synchronized: yes"
# 2. if only 443 is open: sync from HTTPS headers
sudo apt install htpdate
sudo htpdate -s https://www.example.orgUndo the hardcoded IP. The broker needs SNI, so connect by host name, and the certificate is checked against that name anyway, which is why you got the mismatch. Plain client.tls_set() with the system CA bundle is fine; Tyler, no client certificate is needed for token logins, the server asks for one but doesn’t require it.
Also make the script wait for a synced clock before connecting, otherwise a reboot in the lab breaks it again. A quick loop on timedatectl show -p NTPSynchronized works. See the TLS section of MQTT.
Von English mit KI übersetzt ·
Die IT hat mir den internen NTP-Server gegeben, die Uhr stimmt, der Hostname ist wieder eingetragen, beim ersten Versuch hat es sich verbunden. Außerdem habe ich die Warteschleife für die Synchronisation in die systemd-Unit eingefügt. Kaum zu glauben, dass es am Datum lag.
IT gave me the internal NTP server, clock is right, host name back in, connected on the first try. Added the wait-for-sync loop to the systemd unit too. Can’t believe it was the date.
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
Mitdiskutieren
Melde dich an, um Fragen zu stellen und zu beantworten, hilfreiche Beiträge mit „Gefällt mir“ zu markieren und die Antwort zu kennzeichnen, die dein Problem gelöst hat. Jeder Beitrag bringt Punkte und Stufen.