Troubleshooting guide · website-errors · Published 2026-08-16 · 3 min read
Website errors: ERR_CERT_DATE_INVALID before the certificate start date
Fix ERR_CERT_DATE_INVALID from a clock set before a certificate start date, covering device and server clock fixes.
- ·Identify the error
- ·Fix the clock
- ·Prevent recurrence
ERR_CERT_DATE_INVALID is the browser message for a certificate whose validity window does not cover the current time. The usual cause is an expired certificate, but this article covers the less obvious case: a clock that is set before the certificate start date, making a valid certificate appear "not yet valid".
Identify the error
- Read how far off the time is. The browser or
openssloutput often says the certificate is "not valid until" a future date. If today (as the certificate issuer sees it, and as your device reports it) is before that date, a clock is the prime suspect. - View the certificate details. Click the padlock and inspect the certificate, or use
openssl s_client -connect example.com:443 -showcertsto print the validity (notBeforeandnotAfter) and the current date. Compare them. - Rule out a genuine expiry. If the wall clock is correct and the certificate has already passed
notAfter, fix the certificate via renewal (see the certificate errors guide) rather than the device clock.
Fix the clock
- Fix the device clock first. On your machine, set the correct date, time, time zone, and enable automatic time synchronisation. On Windows, Settings > Time & Language > Date & time; on macOS, System Settings > General > Date & Time. A reboot usually follows to re-sync the TLS-validated time.
- Test again. After syncing, reload the page. If it loads and the padlock is valid, the device clock was the cause.
- Check the server clock if clients still fail. If visitors across many devices see the same error, the server may be out of time. Confirm the host clock is synced to the correct time and that NTP is running, because a server that signs session data with a bad clock can also break TLS connections.
Prevent recurrence
- Enable NTP and automatic time. Automatic time synchronisation prevents a drift into the pre-expiry or post-validity window.
- Move the start date assumption. Certificates are valid from
notBefore. A freshly issued certificate is rarely the problem for real users, because issuance setsnotBeforein the past by design, but an old device clock can still predate it. - Know when to check the cert. If your clock is correct and the certificate genuinely has not started or has expired, reissue via your CA or host rather than working around the date.
When to involve a professional
If the error persists after the device and server clocks are verified accurate, or it appears site-wide for visitors on multiple devices, raise it with your hosting provider: it usually points at a genuine certificate or server configuration problem rather than a local clock.