The setup was simple: a Raspberry Pi at home, running a small self-hosted service behind a Let's Encrypt certificate, working fine for months. Then, after an unrelated power outage, it came back online and every HTTPS connection to it started failing — not with a specific, informative error, just a generic certificate validation failure from every client that tried to connect.
The obvious suspects got checked first: was the certificate actually expired? No — checking the file directly showed weeks of validity left. Was the private key mismatched somehow? No — a manual key-matches-certificate check passed cleanly. Was the intermediate chain missing? No, still intact, unchanged since the last successful connection before the outage.
The detail that didn't fit
What finally prompted the actual answer was running date directly on the Pi out of sheer process of elimination — and discovering the system clock was reporting a date from several years in the past. The Raspberry Pi has no battery-backed real-time clock by default; it relies on network time sync at boot to figure out the current date. The power outage, plus a flaky router that hadn't fully come back online yet, meant the Pi booted without network access, silently fell back to whatever its internal clock last remembered (effectively the last time it was manually set, long before), and had been serving traffic with system time years in the past ever since.
A certificate's validity window is checked against whatever the checking client — or in some validation contexts, the server itself — believes the current time to be. A device with a wrong-but-plausible-looking system clock doesn't usually throw an obvious "your clock is wrong" error; it just concludes, incorrectly but internally consistently, that a perfectly valid certificate is either expired or not yet valid.
The actual fix
Once network connectivity came back fully, a manual sudo ntpdate forced an immediate time sync rather than waiting for the next scheduled one, and the certificate validated correctly again instantly — nothing about the certificate itself had ever been the problem. The longer-term fix was making sure the boot sequence didn't proceed with any service depending on TLS until network time sync had actually completed, rather than racing ahead on a stale clock.
Why this is worth knowing even outside hobbyist setups
This is a small, home-lab version of a failure mode that shows up in embedded devices, IoT hardware, and any system without a reliable real-time clock more broadly — see our clock skew troubleshooting guide for the general pattern. The specific lesson worth carrying forward: when a certificate that was definitely working suddenly isn't, and nothing about the certificate itself has changed, checking the actual system clock on both ends is a five-second step that's easy to skip precisely because it seems too basic to be the cause.
This case study is written to illustrate a genuine, common troubleshooting pattern. It is not a direct quotation or a verified account tied to a specific, identifiable individual or company. For the underlying technical reference, see: Fixing Clock Skew SSL Errors
Loading comments…