How to Fix the NET::ERR_CERT_DATE_INVALID Error

NET::ERR_CERT_DATE_INVALID is one of the narrowest errors Chrome raises. It is not a verdict on who issued the certificate, on the domain it was issued for, or on the strength of the encryption. It says one thing only: at the moment of the connection, the browser’s clock fell outside the period the certificate is valid for.

That leaves two possibilities, and they have almost nothing in common. This guide separates the two, shows how to tell within a minute which one you are looking at, and gives the procedure for each.

Quick answer:

NET::ERR_CERT_DATE_INVALID means the browser compared its own clock against the certificate’s validity window and landed outside it. Every certificate carries two timestamps, notBefore and notAfter, and the connection is refused if the current time is earlier than the first or later than the second.

So there are only two causes: the certificate genuinely expired or has not started yet, which the site owner fixes by renewing it, reinstalling the full chain, testing the configuration and reloading the web server, or the device clock is wrong, which the visitor fixes by turning automatic time synchronization back on. Chrome usually tells you which one it is: when it can detect that the clock is off, it shows a separate page headed Your clock is behind or Your clock is ahead instead of the usual warning.

This is not an untrusted-issuer error, that one is NET::ERR_CERT_AUTHORITY_INVALID.

What NET::ERR_CERT_DATE_INVALID Actually Means

Every publicly trusted certificate carries two timestamps that define the only period it may be used for. notBefore is the instant it becomes valid, and notAfter is the instant it stops being valid. Nothing about that window is negotiable and nothing renews it in place: a certificate cannot be extended, only replaced.

During the TLS handshake the browser reads those two values and compares them against its own idea of the current time. If the comparison puts the connection outside the window, validation stops there. Note what the browser is comparing against. It has no independent knowledge of the real time, so it uses the clock of the device it is running on. A correct certificate on a device with a wrong clock and a genuinely expired certificate on a correct device produce exactly the same result.

Chromium tracks this internally as error -201. Its source describes it as a certificate “that, by our clock, appears to either not yet be valid or to have expired”, and lists three situations that produce it:

1. An attacker is presenting an old certificate for which they have managed to obtain the private key.
2. The server is misconfigured and is not presenting a valid certificate.
3. The clock is wrong.

The phrase “by our clock” is the part worth holding on to, and so is what the list leaves out. Nothing there concerns the issuer of the certificate, the browser cache, the DNS resolver, or the network you are on.

This is not the untrusted-authority error

A certificate issued by a Certificate Authority the browser does not trust produces a different code, NET::ERR_CERT_AUTHORITY_INVALID, tracked as -202. The two errors are frequently mixed up because both appear under the same Your connection is not private headline, but they fail at different stages and have different fixes:

• NET::ERR_CERT_DATE_INVALID (-201): the browser identified the issuer and trusts it, then rejected the certificate on its dates. That is this page.
• NET::ERR_CERT_AUTHORITY_INVALID (-202): the browser could not link the certificate to a trusted root at all, usually because the server omits the intermediate certificate or the certificate is self-signed. Dates play no part in it.
• NET::ERR_CERT_COMMON_NAME_INVALID (-200): the certificate is trusted and in date, but was issued for a different hostname. See how to fix ERR_CERT_COMMON_NAME_INVALID.

Read the code printed under the warning text before you change anything. Renewing a certificate will not clear -202, and installing a missing intermediate will not clear -201.

What other browsers call it

The mechanism is identical everywhere, only the naming changes. Firefox is more precise than Chrome here, because it uses a separate code for each half of the problem:

• Chrome, Edge, Brave and Opera (all built on Chromium) show NET::ERR_CERT_DATE_INVALID for both cases.
• Firefox reports SEC_ERROR_EXPIRED_CERTIFICATE when the certificate has passed its notAfter date, and MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE when its notBefore date is still in the future. It has matching codes for an expired or not-yet-valid intermediate, SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE and MOZILLA_PKIX_ERROR_NOT_YET_VALID_ISSUER_CERTIFICATE.
• Safari prints no code and says the connection is not private or that the certificate is not valid.

Because it is the same check, a server-side fix resolves every browser at once. A fix that works in only one browser is a sign you treated a symptom.

Expired and Not Yet Valid Are the Same Code

Almost every guide to this error treats it as an expiry error. That is half of it. Chromium’s own description covers both ends of the window, and the second half explains a set of cases that otherwise look inexplicable.

Past the notAfter date: expired

This is the familiar case. The certificate was valid, its window closed, and it was not replaced in time. Every visitor sees the error at once, on every device, and it appears at a predictable moment rather than gradually.

The same result comes from a device clock set into the future. If a laptop thinks it is 2031, every certificate it encounters has a notAfter date in its past, so every HTTPS site fails, not just one.

Before the notBefore date: not yet valid

A certificate whose validity has not started yet is rejected just as firmly as one that has ended. This half is missing from most troubleshooting pages, and it accounts for the confusing reports:

• A device whose clock is behind. A machine that has lost its clock, typically to a dead CMOS battery, a factory reset, or a long spell powered off, comes back somewhere in the past. From there, every certificate on the internet has a notBefore date in the future, so every HTTPS site fails at once. Chrome’s error page for this reads Your clock is behind.
• A certificate installed the moment it was issued. If the visitor’s clock is running a few minutes behind the CA’s, a brand-new certificate can be read as not yet valid for a short period after installation. Many CAs set notBefore slightly in the past to absorb exactly this (Let’s Encrypt backdates it by an hour), but not all of them do, and the tolerance is not unlimited.
• A certificate issued ahead of a planned rotation. Certificates obtained in advance for a scheduled migration carry a future start date on purpose. Deploying one early produces this error until its window opens.

Chrome Often Tells You Which Side the Problem Is On

Chrome does not always show the same page for -201. When it can establish that the device clock is wrong, it replaces the generic certificate warning with a dedicated clock page, and that switch is the fastest diagnostic available to you.

• Your clock is behind or Your clock is ahead, with the tab titled Clock error and, on most platforms, a single button reading Update date and time. Chrome has concluded your device time is wrong. The site’s certificate is very probably fine.
• Your connection is not private, with NET::ERR_CERT_DATE_INVALID printed underneath. Chrome has no reason to think your clock is wrong, so it is reporting the certificate as genuinely out of date.

The clock page also states the device time it is objecting to, so you can compare it against the real time without leaving the browser. Unlike the standard certificate warning, it gives you no way to continue to the site. It does have an Advanced button, but that only expands a note explaining why a correct clock is needed, with no proceed link underneath it. That is deliberate: with the clock wrong, the browser cannot meaningfully validate any certificate at all.

How Chrome decides your clock is wrong

Chrome compares the system clock against a network time signal, allowing for the measurement uncertainty plus a five-minute margin. When no network time is available, it falls back to a coarser check against the date the browser build was produced: more than two days earlier than the build counts as a clock in the past, more than 365 days later counts as a clock in the future.

Two consequences follow. Small drift does not trigger the clock page, so a clock a few minutes out can still push you outside a validity window that has only just closed or has not quite opened while Chrome shows you the ordinary warning. And the fallback check is loose, so a browser that has not been updated in a long time can miss a wrong clock entirely. Treat the clock page as a strong positive signal, and its absence as weak evidence rather than proof your clock is right.

Find the Certificate’s Real Dates Before Changing Anything

Both causes are settled by the same two facts: what the certificate’s dates are, and what the real time is. Establish them first and the rest of this guide collapses into one branch.

1. Read the dates in the browser

Chrome still lets you inspect a certificate it has rejected:

1. Click the icon to the left of the address bar (the sliders icon in current Chrome versions, a padlock in older ones).
2. Open the connection details, then choose the certificate entry to open the certificate viewer.
3. On the General tab, read Valid from and Valid to. The Details tab shows the same values as the notBefore and notAfter fields.

DevTools gives you the same information: press F12, open the Security panel (it was labelled Privacy and security in Chrome 134 through 145 and renamed back to Security in Chrome 146), and use View certificate. Either route is fine, but the address bar one is stable across versions.

2. Read the dates from the command line

This is the definitive check, because it reads what the server actually puts on the wire rather than anything cached or repaired locally:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

The output names the window directly:

notBefore=Jun  6 20:44:11 2026 GMT
notAfter=Sep  4 21:42:44 2026 GMT
subject=CN=example.com
issuer=C=US, O=Let's Encrypt, CN=YE2

The -servername flag matters only when you connect straight to an IP address. OpenSSL has filled the SNI hostname in automatically from -connect since version 1.1.1, but an IP gives it nothing to derive, so a server hosting several sites answers with its default certificate rather than the one your visitors see. If the certificate file is already on the server, you can read the same values from disk:

openssl x509 -in example_com.crt -noout -dates

Compare the two. A file on disk with good dates and a live connection with bad ones means the new certificate was installed but the web server was never reloaded, which is one of the most common reasons a renewal appears not to have worked.

3. Confirm from outside your network

Run the domain through our free SSL Checker. It connects from outside, reports the expiry date and the state of the chain, and removes your own machine from the equation entirely. That last point matters here more than on most errors: a scan performed elsewhere cannot be misled by your clock, so if the checker reports the certificate as valid while your browser reports it as expired, you have your answer.

4. Check the real time

Compare your device clock against a phone on mobile data or any independent source, and check the time zone as well as the time. A clock that is right to the minute but set to the wrong zone can sit hours away from real time while looking correct at a glance.

How to Fix NET::ERR_CERT_DATE_INVALID as a Website Owner

If the SSL Checker confirms the dates are genuinely out of range, no visitor can do anything about it and every visitor is being blocked. The steps below take a site from expired back to serving.

1. Renew or reissue the certificate

An expired certificate cannot be extended, repaired, or reactivated. It has to be replaced. The process is the same as ordering the original: generate a fresh key pair and a CSR (Certificate Signing Request), submit it to your CA, and complete domain validation. For a domain-validated certificate this usually finishes in minutes. Organization and extended validation certificates take longer, which is worth knowing before your certificate lapses rather than after.

Reuse of the previous CSR is possible with most CAs, but generating a new key pair is the better habit. Our guide on what happens when an SSL certificate expires covers the wider consequences, which reach past the browser warning into API clients, mobile apps, and anything that will not accept a failed handshake.

Certificate Lifetimes Are Getting Shorter

Renewals will happen more often as certificate lifetimes shrink. From March 15, 2026, public SSL certificates can last no more than 200 days. The CA/Browser Forum has scheduled further reductions to 100 days in March 2027 and 47 days in March 2029.

These are not advisory targets. Chrome enforces exactly this schedule in its certificate verification code, keyed on each certificate’s notBefore date, so a certificate issued past the cap is rejected rather than merely discouraged.

You can stay ahead of the changes by using ACME-driven certificate lifecycle automation, which verifies domains and replaces certificates automatically before they expire.

2. Install the new certificate with its full chain

Your CA delivers the new certificate alongside one or more intermediates. Both go on the server. Concatenate them into a single file, leaf first, then each intermediate working up toward the root:

cat example_com.crt example_com.ca-bundle > fullchain.crt

On nginx, the file passed to ssl_certificate must already contain the chain, since nginx has no separate directive for it:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/ssl/certs/fullchain.crt;
    ssl_certificate_key /etc/ssl/private/example_com.key;
}

On Apache 2.4.8 and later, SSLCertificateFile reads the intermediates from the same file and the old SSLCertificateChainFile directive is obsolete:

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on

    SSLCertificateFile    /etc/ssl/certs/fullchain.crt
    SSLCertificateKeyFile /etc/ssl/private/example_com.key
</VirtualHost>

Our SSL certificate installation tutorials cover the equivalent steps on IIS, control panels, load balancers, and appliances.

3. Test the configuration, then reload

Never skip the syntax test. A web server that fails to start after a certificate change turns a warning page into an outage, and the test costs a second:

sudo nginx -t
sudo systemctl reload nginx

On Apache:

sudo apachectl configtest
sudo systemctl reload apache2

The reload is the step people miss. A running web server holds its certificate in memory and keeps serving the expired one until it is told to re-read the file, which is why a renewal can look complete on disk while every visitor still sees the error. Reload rather than restart where you can, since reload applies the new certificate without dropping current connections.

Anything else that terminates TLS needs the same treatment. A load balancer, a CDN, a reverse proxy, or a mail or application server presenting the same certificate each holds its own copy, and updating the origin alone leaves the old dates in front of it.

4. Verify the new dates are actually being served

Confirm from outside, not from the server. Run the same OpenSSL command as before and check that notAfter has moved:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates

Then scan the domain with the SSL Checker for an independent view of the dates and the chain. Check the www and non-www forms, and any subdomain covered by the same certificate, since it is easy to update one virtual host and leave a second one pointing at the old file.

5. Check the intermediate certificate’s dates too

Validation checks the dates of every certificate in the chain, not just yours. An intermediate that has passed its own notAfter date breaks the chain and produces the same code, even though your certificate is current. The symptom is distinctive: the error appears without anything changing on your server, and your own certificate looks perfectly valid when you inspect it.

The -showcerts flag prints every certificate the server sends so you can check each one:

openssl s_client -connect example.com:443 -servername example.com -showcerts

The fix is to replace the intermediate with the current one from your CA’s repository and reload. See our guide on the expired intermediate SSL certificate for the full procedure.

6. Check the server’s own clock

A server with a drifting clock causes trouble in both directions. It can present a certificate that is fine by real time while its own logs and monitoring disagree, and it will fail its own outbound TLS connections, which breaks ACME renewals and leaves you with an expired certificate for reasons that have nothing to do with the CA.

On a systemd-based Linux server, check whether synchronization is running:

timedatectl status

If NTP service is inactive, enable it:

sudo timedatectl set-ntp true

Virtual machines and containers are the usual offenders, particularly after a snapshot restore or a suspend, when the guest clock can resume hours or days behind the host.

7. Automate renewal so it cannot happen again

An expired certificate is a scheduling failure, and manual scheduling stops being realistic at 200-day lifetimes, let alone 47. ACME automation handles validation, issuance, and installation on a timer, replacing certificates well before they lapse. Our ACME tutorials cover the common clients.

Automation only helps if it is verified. Renewal jobs fail silently for ordinary reasons: a validation path stops being reachable, a hook that reloads the web server is removed, a firewall rule changes. Test the whole cycle without issuing anything:

sudo certbot renew --dry-run

Confirm the renewal also reloads whatever terminates TLS. A certificate that renews on disk but never reaches the running web server produces this error on exactly the schedule the automation was supposed to prevent.

8. Monitor expiry independently

Do not rely solely on the CA’s reminder emails. They go to whichever address was on the order, which is often someone who has left, and they say nothing about whether the new certificate reached the server.

Monitor the live endpoint instead. This command exits with a non-zero status when the certificate a server is presenting will expire within the given number of seconds, which makes it straightforward to run from cron or any monitoring system. Here it checks for expiry within 14 days:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -checkend 1209600

It prints Certificate will not expire and exits 0 while there is time left, and Certificate will expire with a non-zero exit once the threshold is crossed. Because it tests the connection rather than a file, it catches the failure mode automation misses: a renewed certificate that never made it into the running server.

How to Fix NET::ERR_CERT_DATE_INVALID as a Website Visitor

There is exactly one thing on your side of the connection that can produce this error, and it is the clock. Nothing else you control affects the comparison between the current time and the certificate’s dates. That is unusual among certificate errors, and it is good news: if the clock is the cause, the fix takes under a minute.

Before you change anything, check whether the error follows you to other websites. If several unrelated HTTPS sites fail at once, the clock is almost certainly the cause. If only one site fails, its certificate is out of date and nothing you do locally will help.

1. Set your device clock correctly

Set the time automatically rather than by hand. Manual entry is accurate to the minute at best, drifts again, and does not fix the time zone. If Chrome showed you the clock page, its Update date and time button takes you straight to these settings.

On Windows 11 and Windows 10:

• Open Settings, go to Time & language, and select Date & time. Right-clicking the clock in the taskbar and choosing Adjust date and time lands in the same place.
• Turn on Set time automatically and Set time zone automatically.
• Click Sync now to force an immediate synchronization, and confirm the time zone shown is the one you are actually in.

If the Sync now button reports a failure, the Windows Time service may be stopped. From an elevated Command Prompt or PowerShell:

w32tm /resync

On macOS (Ventura and later):

• Open the Apple menu, then System Settings.
• Click General in the sidebar, then Date & Time.
• Turn on Set time and date automatically and Set time zone automatically using your current location.

On macOS Monterey and earlier the same settings live under System Preferences and Date & Time, where you first click the lock icon and enter an administrator password.

On Linux: most desktop distributions expose the setting under Settings and Date & Time. From a terminal on a systemd system, check the current state and enable synchronization:

timedatectl status
sudo timedatectl set-ntp true

Set the zone in the same tool if it is wrong, for example:

sudo timedatectl set-timezone Europe/London

On Android: open Settings, go to System, then Date & time, and turn on the automatic option (labelled Automatic date and time, Set time automatically or Use network-provided time depending on the version and manufacturer) along with the automatic time zone setting. On some Samsung and other manufacturer builds the menu sits under General management rather than System.

On iPhone and iPad: open Settings, go to General, then Date & Time, and turn on Set Automatically. If the switch is greyed out, check for a configuration profile or a Screen Time restriction managing it. Chrome on iOS points you at this same screen from its clock error page.

Reload the page after the clock updates. If the clock was the cause, the site loads immediately with no browser restart needed.

2. If the clock keeps resetting, fix the cause

A clock that returns to a wrong date after every shutdown usually means a flat CMOS battery on a desktop or an older laptop. The battery is inexpensive and the symptom is diagnostic: the machine boots with a date years in the past, and every HTTPS site fails until the clock synchronizes.

Two other recurring causes are worth knowing. Dual-boot systems running Windows and Linux disagree about whether the hardware clock is local time or UTC, which shifts the clock by the size of your time zone offset on every switch between them. And virtual machines can resume from a snapshot with a stale clock until synchronization catches up.

3. If your clock is already right

Then the certificate really is out of date and the problem is on the website’s end. Nothing on your device will change that. Confirm it by running the domain through the SSL Checker, which will name the expiry date, and report it to the site operator if you have a way to reach them. Expired certificates are usually replaced within hours once someone notices, so trying again later is often all that is needed.

4. Do not set your clock back to get past the warning

Moving your clock into the past makes an expired certificate look valid again, and it is a bad idea in every case. You are not repairing anything, you are switching off the check that tells you whether the certificate you are being shown is still the one the site is supposed to be using. That check exists partly to stop an attacker reusing an old certificate whose private key has since leaked, which is the first situation Chromium lists for this error.

The side effects are real too. A wrong system clock breaks other HTTPS connections, software updates, two-factor authentication codes, and scheduled tasks, and it tends to be forgotten until something else fails for reasons nobody connects back to it.

The same reasoning applies to clicking through the warning. On a development server whose certificate you know has lapsed, proceeding is a reasonable shortcut. On a site where you sign in, enter payment details, or handle anything you would not want intercepted, an unexplained certificate warning is worth taking at face value.

What Will Not Fix This Error

These steps circulate widely for certificate errors in general. None of them can change a certificate’s dates or the system clock, so none of them resolves -201. They are listed here so you can rule them out quickly rather than work through them.

• Clearing the cache and cookies. Certificates are not stored in the browsing data cache. The server transmits its certificate during the handshake on every new connection, so there is nothing stale to clear.
• Clearing the SSL state. Widely copied as “clear your SSL slate”, which is a misspelling of SSL state, and the route usually quoted with it (Chrome Settings, then Show advanced settings, then Change proxy settings) describes a Chrome interface that was removed years ago. The underlying Windows control does still exist, under Internet Properties on the Content tab, but what it clears is cached client-certificate selections and TLS session state on your machine. It cannot alter a certificate’s notBefore and notAfter values, and it cannot correct your clock.
• Changing your DNS server. DNS resolves a hostname to an IP address and stops there. It has no role in certificate validation and cannot affect the dates inside a certificate. Changing resolvers is worth trying when a site will not resolve at all, not when it resolves, connects, and presents a certificate the browser then reads as out of date.
• Leaving public Wi-Fi. A captive portal at a hotel or airport can intercept requests before you sign in, but the warning that produces is normally a name mismatch, because the portal answers with its own certificate for a different hostname. It does not change validity dates. The one real connection is indirect: a device that has been switched off for a long time can come back with a badly drifted clock at the same moment you join an unfamiliar network, which makes the network look responsible when the clock is.

Antivirus software: the narrow version of that advice

“Turn off your antivirus” appears on nearly every page about certificate warnings, and for this specific error it is close to a dead end. Security products that inspect HTTPS traffic work by terminating the connection themselves and re-signing it with a root certificate they installed on your machine. When that goes wrong, the browser rejects the substituted certificate because it cannot trace the issuer back to a trusted root. That is NET::ERR_CERT_AUTHORITY_INVALID, a different code with a different page. It is an issuer mechanism, not a date one.

Check the certificate viewer before spending time here. If Issued By names your security product or your employer, you are on the wrong guide. If it names a public CA and the dates are simply in the past, no antivirus setting will move them.

If you still want to rule it out, turn off only the HTTPS scanning or SSL filtering component, which lives under the product’s web or network protection settings. Do not disable the antivirus itself. Switching off the whole product removes protection you still need and tells you nothing that disabling the one responsible feature does not.

The Companion Code: NET::ERR_CERT_VALIDITY_TOO_LONG

One neighbouring code is worth recognizing so you do not confuse it with this one. NET::ERR_CERT_VALIDITY_TOO_LONG, tracked by Chromium as -213, is the opposite of an expired certificate: its validity window is longer than the maximum that applied when it was issued, so Chrome refuses it outright rather than on its dates. The check is keyed on the issue date and not on today’s, so certificates issued under an older cap keep working normally until they expire. No configuration suppresses it, and the only fix is to ask your CA to reissue within the current limit.

Frequently Asked Questions

For more SSL error troubleshooting, check our detailed tutorials about fixing different SSL errors.