I am running Mosquitto 2.0.11 which is the stable version for Debian 12.
I generated ca server and client certificates and csr from youtube video. The Debian 12 computer is on default local time zone which is not same time zone as London (not GMT/UTC+0)
Raspberry Pi Pico W board running Micropython (latest 1.24.1) can connect with mosquitto when the pico board is set to local time (not UTC) by Thonny IDE during connection to pico.
When I programed the pico board to read time from NTP server, it got UTC time. UTC is different from the local time and the pico failed to connect with mosquitto
======
Question 1. Where does Mosquitto got it time?
I believe Mosquitto uses openssl library for TLS?
I believe Debian PC follow the ‘normal convention’ of setting the battery backup clock to UTC and use the time_zone value to give the system time which Thonny pick up and send to the pico. I believe pico use MBed TLS library.
Multiple youtube videos show generation of certificate without mentioning of setting PC time either to local time or UTC (GMT+0). Does the certificates carry time_zone information and need to be setup in a particular manner?
Question 2. How can I get these to work? Web search says TLS library should use UTC for all connected devices (pico and debian pc)
Question 3. What time accuracy is needed between the pico and mosquitto. Web info says 10 seconds to 5 minutes?
Hi, let me see if I can answer your questions as expected:
Where does Mosquitto get its time?**
Yes, Mosquitto uses OpenSSL for handling TLS. Since OpenSSL relies on the system time, Mosquitto gets its time from the underlying Debian system.
In Debian, the system time is managed by the systemd-timesyncd service (if enabled) or ntpd/chronyd, which syncs with an NTP server. Debian follows the typical convention where the hardware clock (RTC) is set to UTC, and the system timezone is applied separately.
Do certificates carry timezone information?
No, X.509 certificates (used in TLS) do not store timezone information explicitly. Instead, all timestamps in the certificates, including the Not Before and Not After fields, are stored in UTC format.
This means:
If your Pico is set to local time instead of UTC, it may interpret the certificate validity incorrectly.
If there is a significant time mismatch between Pico and Mosquitto, the TLS handshake will fail because the certificate might appear as “not yet valid” or “expired.”
Make sure both server use UTC.
What time accuracy is needed?
TLS libraries generally require the system clock to be within a few minutes of the correct time for certificate validation. The acceptable range depends on implementation:
OpenSSL (used by Mosquitto) typically allows a tolerance of a few minutes (default is 5 minutes).
Pico could be stricter
To be safe, keep the Pico’s time within 10 seconds of the Mosquitto server’s time.
Summary
Set Debian time to UTC (sudo timedatectl set-timezone UTC).
Ensure Pico W syncs with NTP before connecting.
Debug Mosquitto logs if the issue persists. (log_type all)
Hi Tizian, many thanks for detailed and prompt reply.
It was my programming mistake. Now, I can confirm that the pico, either set to UTC or local time that is a few hours different from UTC, can communicate with Mosquitto. Since the certificates at both side have expire days of years, a few hours from UTC did not affect the expire time check.
Some human replies (not sure if 100% correct) from my web search said time is not in the TLS RFC specification and individual implementation can differ. Yes, default 5 minutes were mentioned on multiple web search result.
“AI” said, apart from expire cert check, TLS also uses accurate time to counter message-replay attack and hence accurate time is important. May be this is not checked in my installation. openssl is used in Mosquitto and I believe another TLS lib is used on pico.