Nouveau : le pare-feu IA surveille toute la plateforme et explique chaque incident en termes simples. Découvrez comment ça marche

Re : paho-mqtt sur un Pi 3 de laboratoire échoue au handshake TLS avec « certificate is not yet valid »

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.org

Supprimez 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.

If it isn't logged, it didn't happen.
Solution acceptée♥ 5