Traduit de English par IA ·
Étudiant ici, premier message. Je réalise un enregistreur d’humidité du sol pour un projet de laboratoire : Pi 3, capteur capacitif via un ADS1115, paho-mqtt 1.6, envoi vers Hermetry sur 8883. Sur mon Wi-Fi personnel, tout fonctionne. Au laboratoire, cela échoue à chaque fois :
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: certificate is not yet valid (_ssl.c:1006)Le réseau du laboratoire bloque beaucoup de choses, j’ai donc aussi essayé de me connecter à l’adresse IP du broker au lieu du nom d’hôte (je l’ai résolue chez moi et codée en dur), et l’erreur devient alors une non-correspondance du nom d’hôte. J’ai réinstallé certifi et appelé client.tls_set() avec et sans le chemin ca_certs. Rien n’y fait. Est-ce le pare-feu du laboratoire qui perturbe TLS ?
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?
Traduit de English par IA ·
Le port 8883 est-il seulement ouvert sur ce réseau ? Certains endroits n’autorisent que les ports 80 et 443 en sortie.
Is 8883 even open on that network? Some places only allow 80 and 443 out.
Traduit de English par IA ·
Il doit être ouvert, le handshake démarre, il échoue simplement sur le certificat.
It must be open, the handshake starts, it just fails on the certificate.
Traduit de English par IA ·
Peut-être avez-vous besoin d’un certificat client pour le broker ? Nous avons dû en charger un sur nos PC de ligne.
Maybe you need a client certificate for the broker? We had to load one on our line PCs.
Traduit de English par IA ·
Qu’affiche date sur le Pi quand vous êtes au labo ?
What does date say on the Pi when you’re in the lab?
Traduit de English par IA ·
…il indique mars de l’année dernière. Chez moi, c’est correct.
…it says March of last year. At home it’s right.
Traduit de English par IA ·
Voilà, c’est donc ça. Un Pi 3 n’a pas d’horloge temps réel. Au démarrage, il restaure l’heure enregistrée lors de l’extinction propre précédente (fake-hwclock), puis attend NTP. Votre réseau de laboratoire bloque NTP (UDP 123), donc l’horloge reste dans le passé et, pour la bibliothèque TLS, le certificat du serveur n’est pas encore valide. J’ai vu cela sur la moitié des Pi déployés que j’ai mis en service derrière des pare-feu verrouillés.Solutions, à choisir :
# 1. demander à l'informatique le serveur NTP interne et l'utiliser
sudo nano /etc/systemd/timesyncd.conf
[Time]
NTP=ntp.your-lab.example
sudo systemctl restart systemd-timesyncd
timedatectl # "System clock synchronized: yes"
# 2. si seul le port 443 est ouvert : synchroniser via les en-têtes HTTPS
sudo apt install htpdate
sudo htpdate -s https://www.example.orgSupprimez l’IP codée en dur. Le broker nécessite SNI, il faut donc se connecter par nom d’hôte ; le certificat est de toute façon vérifié par rapport à ce nom, ce qui explique la non-correspondance. Un simple client.tls_set() avec le bundle de CA du système convient ; Tyler, aucun certificat client n’est nécessaire pour les connexions par jeton, le serveur en demande un mais ne l’exige pas.Faites aussi attendre au script une horloge synchronisée avant de se connecter, sinon un redémarrage au laboratoire le fera à nouveau échouer. Une boucle simple sur timedatectl show -p NTPSynchronized fonctionne. Voir la section TLS de 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.
Traduit de English par IA ·
Le service informatique m’a donné le serveur NTP interne, l’horloge est juste, le nom d’hôte est de nouveau renseigné, connexion réussie du premier coup. J’ai aussi ajouté la boucle d’attente de synchronisation dans l’unité systemd. Difficile de croire que c’était la date.
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.
- Vous devez être connecté pour répondre à ce sujet.
Rejoignez la discussion
Connectez-vous pour poser et répondre à des questions, aimer les messages utiles et marquer la réponse qui a résolu votre problème. Chaque contribution rapporte des points et des niveaux.