ERR_CERT_DATE_INVALID

The short version: Check your device's date and time first, because the browser judges the certificate against your clock and a wrong one makes a valid certificate look expired. If the clock is right, verify the real expiry with openssl s_client. If it has genuinely lapsed, only the website owner can fix it by renewing and, importantly, reloading the server so the new certificate is actually served.

Key takeaways

• ERR_CERT_DATE_INVALID means the certificate is outside its validity window. It has either expired or has not yet become valid, so the browser refuses the connection.
• Check your own clock first. The browser compares the certificate against your device's time, so a wrong system date makes a perfectly good certificate look expired.
• One device failing while others work almost always means the device is at fault. A genuinely expired certificate fails for every visitor everywhere, simultaneously.
• This is distinct from an authority error, which is about who issued the certificate rather than when it was valid. Dates and trust are separate checks.
• Public certificates are capped at 398 days and Let's Encrypt issues for 90, so renewal has to be automated. Anything relying on someone remembering will eventually lapse.

Error type

HTTPS / TLS certificate error

Whose side

Either: an expired certificate, or your device clock

Fix difficulty

Easy for a visitor, moderate for an owner

Common cause

The certificate is outside its validity window

What does ERR_CERT_DATE_INVALID mean?

ERR_CERT_DATE_INVALID is what a browser reports when a certificate fails the validity-period check. Every X.509 certificate carries two timestamps, notBefore and notAfter, defined in RFC 5280, and the browser confirms that the current moment falls between them before trusting anything else about the connection. Failing that check stops the handshake regardless of how legitimate the certificate otherwise is: the issuer can be perfectly trusted and the hostname can match exactly, and it still will not connect. This is deliberate, because a certificate whose lifetime has ended may have had its private key compromised in the meantime, and the expiry date is the mechanism that limits that exposure.

The catch is that "the current moment" comes from your own device. A browser has no independent notion of the time, so a machine whose clock is wrong by days or years will reject certificates that everyone else accepts, and will occasionally accept ones it should not. That is why a wrong system clock and a genuinely expired certificate produce the same message, and why the two must be told apart before anything is fixed. A single device failing while everything else works points at the clock. Every device failing at once points at the certificate.

398 days

The maximum validity period for a public TLS certificate since 2020, down from several years previously

90 days

The lifetime Let's Encrypt issues, chosen deliberately so that renewal has to be automated

2 dates

Every certificate carries notBefore and notAfter, and the browser checks your clock falls between them

How the ERR_CERT_DATE_INVALID error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com

Your connection is not private

example.com's certificate expired. NET::ERR_CERT_DATE_INVALID

ERR_CERT_DATE_INVALID

• ERR_CERT_DATE_INVALID
• NET::ERR_CERT_DATE_INVALID
• Your connection is not private
• This site's security certificate has expired
• Your connection is not private, certificate expired
• The certificate is not yet valid

Date, authority, name and protocol failures

These are four separate checks in the same validation, and each one fails for reasons the others do not.

Which certificate check failed

Browsers report certificate problems separately because each one fails a different part of validation, and the fixes have nothing in common.

What causes ERR_CERT_DATE_INVALID?

• A certificate that has genuinely expired because renewal did not happen, which fails for every visitor at the same moment.
• A device clock or time zone set incorrectly, which makes a valid certificate appear expired or not yet valid on that device alone.
• A renewal that succeeded on disk but was never loaded, so the server keeps serving the old certificate until it is reloaded or restarted.
• An automated renewal that stopped silently: an expired ACME account, a failing HTTP or DNS challenge, or a scheduled job that no longer runs.
• A certificate that is not yet valid, which happens after issuing one ahead of time or when a server's clock runs behind.
• Only some servers behind a load balancer holding the renewed certificate, so the error appears intermittently depending on which one answers.
• Security software or a corporate proxy substituting its own certificate for inspection, where that substitute has itself expired.

How to find the cause fast

1. Check the device's date, time, and time zone. A clock that is wrong explains the error immediately and costs nothing to rule out.
2. Read the real validity dates from the server with openssl s_client, rather than trusting what the browser summarises.
3. Test from another device on another network. Universal failure means the certificate; one device failing means that device.
4. If the certificate on disk looks current but the served one does not, the server was never reloaded after renewal.

Terminal

echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -datesnotBefore=Apr 2 00:00:00 2026 GMTnotAfter=Aug 31 23:59:59 2026 GMT# the window closed yesterday: this one really has expired

How ERR_CERT_DATE_INVALID looks from the outside

A certificate expiring is one of the few outages you can know about weeks in advance, which is what makes it such an avoidable one. Nothing degrades on the way there: the website is completely healthy right up to the second the window closes, then every visitor gets a full-page security warning at once. A plain uptime check will not help, because the server is up and answering; it is the certificate that stopped being acceptable. Watching the expiry date itself, and alerting well before it arrives, turns the most predictable failure in web hosting into a task with a deadline rather than an incident.

How to fix ERR_CERT_DATE_INVALID

If you are a visitor

1. Check your device's date, time, and time zone, and enable automatic time setting. This is the single most common cause when other people can reach the website normally.
2. Try the same page on another device or network. Working elsewhere confirms the certificate is fine and your device is not.
3. Restart the browser after correcting the clock, since it may have cached the failed validation.
4. Disable HTTPS scanning in any security suite, which substitutes its own certificate and can present an expired one.
5. If every device fails, the certificate really has expired and there is no visitor-side fix. Do not click through the warning on any website where you enter information.
6. On an older operating system, install pending updates, since an outdated trust store can misjudge modern certificate chains.

If you run the website

1. Confirm what the server is actually serving with openssl s_client, not what is sitting on disk. The two differ whenever a reload was missed.
2. Renew the certificate, then reload or restart the web server so the new one is loaded into the running process.
3. Find out why automation did not fire: check the renewal timer or cron job, the ACME account status, and whether the HTTP or DNS challenge is still passing.
4. Make sure every server behind a load balancer received the new certificate, since a single stale node produces an error that comes and goes.
5. Automate renewal if it is still manual. With a 398-day cap and 90-day Let's Encrypt certificates, manual renewal is a deadline someone will eventually miss.
6. Set the renewal to run well before expiry, typically at 30 days remaining, so a failed attempt has time to be noticed and retried.

Still not fixed? Next steps

• Confirm the device clock and time zone before anything else. It costs seconds and explains a large share of single-device reports.
• Check the actual expiry from the command line rather than from the browser, so you are reading the certificate the server is serving right now.
• Test from a second device on a different network. Failing everywhere means the certificate has genuinely lapsed; failing on one device means that device is the problem.
• If it has expired, find out why the renewal did not run: an expired ACME account, a failed challenge, a cron job that stopped, or a reload that never happened after a successful renewal.
• Remember that renewing is only half the job. A certificate renewed on disk but never loaded by the running server keeps serving the old one until it is reloaded.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Read the certificate the server is actually serving

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates -subject
# notBefore=Apr  2 00:00:00 2026 GMT
# notAfter =Aug 31 23:59:59 2026 GMT

Check how many days are left, for a script or a cron job

exp=$(echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
echo "expires in $(( ($(date -d "$exp" +%s) - $(date +%s)) / 86400 )) days"

Renewing is not enough on its own

# the certificate on disk is new, the running process still holds the old one
certbot renew --quiet
systemctl reload nginx     # <- without this, nothing changes for visitors

How to prevent ERR_CERT_DATE_INVALID

An expired certificate is the most predictable outage there is: the date is known months ahead, nothing degrades on the way there, and then every visitor sees a full-page security warning at the same moment. An ordinary uptime check will not catch it either, because the server is up and answering perfectly well. Pulsetic watches certificate expiry alongside availability and alerts you by email, SMS, voice call, Slack, Discord, Telegram, or webhook with weeks of warning, which turns the whole thing into a scheduled task instead of a Saturday morning.

Learn how Pulsetic's SSL certificate monitoring detects this from the outside, across 15+ locations.

Sources and further reading

The specifications and vendor documentation this guide is written from, plus deeper reading on the parts it only summarises.

• MDN: Transport Layer Security
• RFC 5280: X.509 certificate validity
• Let's Encrypt: certificate lifetimes and renewal
• RFC 5280: Internet X.509 Public Key Infrastructure Certificate