Time, NTP, and TLS are tied together because certificates and many security checks depend on an accurate system clock. On a LogicWeb VPS you should leave the distro NTP client running so the clock stays synchronized. When the clock drifts, TLS can fail even though the certificate itself is valid, and logs or TOTP codes can misbehave at the same time.
Use the distribution’s NTP client, keep UDP 123 open to the pool or your vendor source, and set the timezone on purpose. UTC on the server usually causes the fewest surprises. Setting the clock by hand after NTP was blocked will drift again. Opening NTP, or using the hypervisor time hint, is the real fix.
timedatectl statusCheck the lines for “System clock synchronized” and “NTP service.” If NTP is inactive, nothing is steering the clock. If synchronized is no, the service is up but not getting replies from a reachable source. That often means a firewall rule, a blocked pool, or a broken resolver. chrony can show more detail with chronyc tracking; systemd-timesyncd mainly reports through timedatectl. Either client is fine on a single VPS. Do not run both at once.
How wrong time breaks TLS
TLS clients compare the current time against the certificate’s notBefore and notAfter values. A clock that is days off can make a good certificate look expired or not yet valid. Browsers then report an invalid certificate even though AutoSSL or Let’s Encrypt issued a normal chain. Fix the server clock first, then retest in the browser. On a laptop, also confirm the local clock before you open a ticket about the cert.
When TOTP fails for everyone
TOTP codes are built from a shared secret and the current time step. About thirty seconds of skew can already reject a valid code. An hour of skew can fail every login at once. Confirm NTP is synchronized, wait a minute, then try one fresh code. Only reset staff tokens if you believe the secrets were actually leaked. Mass resets are loud; fixing the clock is usually enough.
Logs, cron, and shared hosting
Logs stamped in the future scramble incident order, and cron follows the system clock rather than a WordPress display timezone. Prefer UTC on the server, show local time in the application, and write ticket times in UTC when you can. The panel timezone is not always the OS timezone, so trust timedatectl over a cPanel clock widget.
On shared hosting you do not run chrony yourself. The node is already synced, and AutoSSL uses that clock. If browsers still reject a certificate, check the laptop clock, leftover HSTS, or a CDN serving an old chain. On a VPS, NTP is yours to keep alive, including after a firewall rebuild that forgot UDP 123.
Tagged
Was this article helpful?
Be the first to rate this article.
