Beyond client-side clock skew (covered separately), a server's own significantly incorrect system clock can cause its own set of SSL problems — including failed certificate issuance or renewal (since ACME validation involves time-sensitive tokens) and the server itself potentially misjudging its own installed certificate's validity.
The fix
Confirm NTP (network time synchronization) is properly enabled and functioning on the server itself, not just on client devices — a server with a drifted clock is a less common but real cause of certificate-related failures that's worth ruling out specifically when troubleshooting issuance or renewal failures that don't have another obvious explanation.
How a server's own incorrect clock causes different symptoms than a client's incorrect clock
An incorrect server clock can cause the server to issue OCSP responses or generate timestamps that appear invalid to a correctly-clocked client, a different and sometimes more confusing failure pattern than the more commonly discussed scenario of an individual client's clock being wrong.
How to set up automatic time synchronization on a server to prevent this permanently
Configuring NTP (or a modern equivalent like systemd-timesyncd) on any server, rather than relying on the system clock remaining accurate indefinitely without correction, prevents the gradual drift that can eventually cause certificate-validation-affecting discrepancies on long-running server infrastructure.
What symptoms specifically point to a server-side clock issue rather than a client-side one
If multiple different clients, with their own correctly synchronized clocks, all report certificate errors against the same server, a server-side clock issue becomes the more likely explanation than each individual client happening to have an independently incorrect clock.
How to check a remote server's actual reported time without direct shell access
Checking the Date header in an HTTP response from the server (visible via curl -I or browser developer tools) shows the server's own reported time as part of a standard HTTP response, giving a way to check server time even without direct shell or SSH access to the machine.
A final note on proactive versus reactive time sync setup
For any server you're responsible for, verifying time synchronization is actually configured and working as part of your standard initial server setup checklist, rather than only addressing it reactively once a clock-related issue has already caused a visible problem, is the more efficient long-term approach.
What the exact command looks like for checking a server's time without shell access
Running curl -sI https://yourdomain.com and examining the Date header in the response shows the server's own reported current time as part of a standard HTTP response, giving you a way to check server time even without direct SSH or shell access to the machine itself.
How virtualized and cloud infrastructure specifically need extra attention for this issue
Virtual machines that have been paused, suspended, snapshotted, or migrated between physical hosts are particularly prone to clock drift compared to continuously running physical hardware — cloud infrastructure specifically benefits from explicit, verified time synchronization configuration rather than assuming default settings are sufficient.
A quick closing checklist
A quick closing checklist covers checking a remote server's reported time via its HTTP Date header, confirming NTP or an equivalent service is actually running and synchronized, and paying particular attention to cloud and virtualized infrastructure given its heightened susceptibility to clock drift.
How this issue can silently affect more than just certificate validation on a server
An incorrect server clock affects considerably more than certificate validation alone — log timestamps, scheduled task timing, and any time-sensitive application logic can all be silently affected, making this a worthwhile check for general server health, not just certificate troubleshooting specifically.