How to fix NET::ERR_CERT_DATE_INVALID
The error means the certificate is outside its validity window. Here is how to tell whether the fault is your server or the visitor's clock, and how to fix each.
NET::ERR_CERT_DATE_INVALID is Chrome's way of saying it does not trust the dates on a site's TLS certificate. The browser replaces the page with a full-screen warning and most visitors leave immediately. The message looks alarming, but the diagnosis is short: either the certificate really is outside its validity window, or the clock on the machine reading it is wrong.
Step 1: find out which side is broken
The fastest way to separate the two cases is to read the certificate from somewhere other than the affected computer. If an external check reports a valid certificate with dates that bracket today, the problem is local to the visitor. If it reports an expired certificate, the problem is on the server and every visitor sees it.
If the certificate has expired
This is the common case and it is entirely on the server side. Renew the certificate, then install the new one and reload the web server. The second half is where most outages actually happen: a certificate that has been renewed at the authority but never deployed leaves the old, expired file still being served.
- Issue or renew the certificate at your certificate authority, or let your ACME client do it.
- Copy the new certificate AND the intermediate chain onto the server. With Let's Encrypt this means fullchain.pem, not cert.pem.
- Reload the web server so the new file is actually loaded. nginx: systemctl reload nginx. Apache: systemctl reload apache2.
- Re-check from outside. If the old expiry date is still reported, the server is still serving the old file.
If the certificate is valid but one machine still complains
Then that machine's clock is wrong. A certificate is only valid between two timestamps, so a device whose date is set weeks in the past or future will reject perfectly good certificates across the whole web, not just on your site. Set the clock to update automatically and the error disappears.
This is worth knowing because it changes who you talk to. If a single customer reports the error and everyone else is fine, you are not looking at a server problem and no amount of reinstalling will help.
If it is neither
Two less common causes produce a date error that is not really about dates. A certificate that is not yet valid, because it was issued in a different timezone and the start date has not arrived, behaves the same way for a few hours. And a server serving several sites can present the wrong certificate entirely if the virtual host configuration does not match the requested hostname, in which case you may be reading the expiry date of some other site's certificate.
Making sure it does not happen again
Certificate lifetimes are shrinking fast. Since March 2026 a newly issued public certificate can be valid for at most 200 days, dropping to 100 days in 2027 and 47 days in 2029. Every cut multiplies the number of renewals per year and therefore the number of chances to miss one.
Two habits cover it. Automate issuance so renewal is not a manual task, and monitor the certificate your server actually serves rather than the one you believe you installed. The two are not the same thing, and only the second one catches a renewal that silently failed to deploy.