Reply To: paho-mqtt on a lab Pi 3 fails the TLS handshake with ‘certificate is not yet valid’

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

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