If you've confirmed your certificate's actual expiry date is genuinely in the future but visitors (or you) are seeing an expired-certificate warning, this is almost always a caching issue rather than an actual configuration problem — a CDN, proxy, or even the browser itself serving a stale, previously-cached certificate rather than the current one.
How to isolate it
Check what's in reality being served with openssl s_client -connect yourdomain.com:443, bypassing any browser cache. If that shows the correct, current certificate but browsers still report it as expired, the issue is client-side caching (test in a private browser window) or a CDN/proxy layer that needs its own cache purged or its own certificate refreshed separately from your origin server.
Why this seemingly contradictory error is almost always a client-side clock issue
If a certificate's actual expiry date (verified independently) is genuinely still in the future, but your system reports it as expired, an incorrect system clock is overwhelmingly the most likely explanation — correcting your system's date and time, covered in more detail in our dedicated clock skew guide, resolves the large majority of these cases.
How to independently verify a certificate's real expiry date without trusting your own system's clock
Checking a certificate's expiry date through an independent online SSL checker tool, which uses its own server-side clock rather than your local system's potentially incorrect one, gives a reliable, independent confirmation of the certificate's actual validity window.
What to do immediately if you suspect this specific clock-related scenario
Checking your system's current date and time against a reliable, independent source (your phone, a world clock website) is the fastest first step — if your system's clock is wrong, correcting it resolves this specific class of false-expiry error immediately.
How this specific scenario differs from a certificate that's, in practice expired
A genuinely expired certificate requires the site owner to renew it — there's no client-side fix available. This clock-skew scenario is the opposite: the certificate itself is fine, and the fix lies entirely on the client's own system settings rather than anything the site owner needs to do.
What the exact steps look like for correcting your system clock on major operating systems
Windows: Settings → Time & Language → enable 'Set time automatically'. macOS: System Settings → General → Date & Time → enable 'Set date and time automatically'. Linux: typically timedatectl set-ntp true — enabling automatic synchronization on any platform prevents this issue from recurring going forward.
How to verify the fix in practice resolved the issue rather than just assuming it did
After correcting your system clock, revisiting the site that previously showed the error confirms the fix in fact worked — occasionally a browser needs a fresh page load or cache clear even after the underlying clock issue is corrected, worth confirming rather than assuming.
How dual-boot systems specifically complicate this particular class of issue
A computer dual-booting multiple operating systems sometimes maintains separate, independently drifting clocks for each OS — if you've recently switched between operating systems on the same machine, checking the clock specifically within your currently active OS is worth doing rather than assuming a single system-wide clock.
Loading comments…