Clock Skew

The tell is that everything broke at once. A certificate error against one server suggests a problem with that server or its chain. Certificate errors against every server in the client, including operators with no relationship to one another, on a configuration that worked the day before, points at the machine's own clock rather than at anything on the network. No provider change can cause that pattern, and nothing at the indexer touches it.

Why certificates fail first

Every certificate carries a not-before and a not-after timestamp, and validation compares both against the local clock. A clock reading a date earlier than issuance produces a not-yet-valid error. A clock reading a date past expiry produces an expired-certificate error against a certificate that is perfectly current. The wording varies between TLS libraries, and all of it points at the certificate, which is why the diagnosis usually starts in the wrong place. Minutes of drift are harmless; the failure needs the clock to be wrong by enough to fall outside a validity window, which in practice means days, months, or a reset to a manufacturer default date somewhere in the past.

Machines that drift

• A desktop with a dead motherboard battery, which loses the time whenever it is unplugged and returns at a fixed default.
• Boards with no real-time clock at all, including most Raspberry Pi models, which start at an arbitrary date and stay wrong until the network supplies the answer. A board that boots faster than its network comes up can attempt its first connections while still in the past.
• Virtual machines resumed from a snapshot or a long suspend, whose guest clock is behind by exactly the time spent paused.
• Dual-boot systems disagreeing about whether the hardware clock holds UTC or local time, which yields a consistent offset the size of the timezone.

Effects other than TLS

Age filters and retention arithmetic are computed against the local date, so a skewed clock makes a client treat recent posts as beyond retention or ancient posts as new. Scheduled downloads and bandwidth windows fire at the wrong hour. Articles posted from the machine carry a Date header that some servers reject outright and that sorts oddly wherever it is accepted. Log timestamps stop lining up with a provider's status page, which matters at the point a problem is being reported.

Correcting it

Enabling network time synchronization is the whole fix: the Windows time service, or systemd-timesyncd, chrony, or ntpd on Linux and BSD. The hardware clock deserves a separate look, since a system corrected at every boot but drifting badly between them signals a failing battery. Containers inherit the host clock, so the host is the place to correct one. Timezone configuration is a distinct setting from the clock itself and a wrong timezone does not break certificates. Once the clock is right, reconnecting the server entry clears the errors immediately.