Some of the strangest outages have a boring root cause: the clock is wrong. When a server's time drifts far enough, TLS handshakes fail with certificate is not yet valid, Kerberos and token auth get rejected, and log timestamps stop making sense — all while the certificates and credentials themselves are perfectly fine.
Why time breaks security
Certificates have a notBefore/notAfter validity window, and auth tokens (JWTs, Kerberos tickets) carry short expiry timestamps. If the local clock is behind, a valid cert looks like it hasn't started yet; if it's ahead, tokens look expired. The check is working exactly as designed — it's the clock that's lying.
Spot it
date # compare against a known-good source chronyc tracking # System time offset, and "Leap status" chronyc sources -v # is any upstream actually reachable?
A large offset or “Not synchronised” means the time daemon isn't keeping up — often because no upstream source is configured, or the network to it is blocked.
Resync and keep it synced
Force the clock back into line immediately with chronyc makestep (a one-shot step, unlike the slow slew chrony normally uses). Then fix the durable cause: make sure /etc/chrony/chrony.conf has a reachable pool or server line and that chronyd is enabled, so the box can never free-run again.
Practise it
Clock skew is one of the trickier Chaos Engine incidents because the error message points at TLS, not time. Train the instinct to check the clock first in Linux troubleshooting practice, and see the cert side in fixing an expired SSL certificate.