Only one site shows this error and my clock is correct. What now?

Then the certificate starts in the future. Check its start date with the certificate decoder or openssl x509 -noout -startdate. The site owner has to reissue the certificate on a machine with the correct time.

Should I click "Accept the Risk and Continue"?

Fix the clock first; that resolves most cases for every site at once. For a device you own, such as a router whose certificate was generated with a wrong date, accepting the exception is acceptable once you have checked the certificate fingerprint. Never do it for banking, email or shopping sites.

Why did this start right after the site renewed its certificate?

A newly issued certificate is valid from the moment of issuance, so a client clock that is behind by more than the age of the certificate rejects it. Shorter lifetimes mean more frequent renewals, so a slow clock hits fresh certificates more often. Correct the clock with network time.

What do Chrome and Safari show for the same problem?

Chrome shows NET::ERR_CERT_DATE_INVALID, sometimes with a "Your clock is behind" page. Safari reports that the certificate is not valid. The fixes are the same.

MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE in Firefox: fix

MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE means the certificate is not valid yet according to your device's clock. If your clock is earlier than the certificate's start date (notBefore), Firefox refuses it. Usually the clock is wrong, not the certificate; otherwise the certificate was generated with a future start date.

What Firefox shows

The page title is "Warning: Potential Security Risk Ahead". Under Advanced, Firefox explains: "Websites prove their identity via certificates, which are valid for a set time period. The certificate for example.com will not be valid until" followed by a date, and lists the error code. Firefox's NSS description of the code reads "The server presented a certificate that is not yet valid."

When Firefox can tell that your clock is off, it may instead show "Your Computer Clock is Wrong" and ask you to update the date, time and time zone in system settings.

A related code, MOZILLA_PKIX_ERROR_NOT_YET_VALID_ISSUER_CERTIFICATE, says "A certificate that is not yet valid was used to issue the server's certificate", meaning an intermediate or root in the chain has a future start date.

Common causes, most frequent first

1. Your device clock is behind

Typical triggers are a dead motherboard battery that resets the date after every power loss, a new or factory-reset device that has not synced time yet, a virtual machine restored from an old snapshot, and a date changed by hand to extend a software trial. If many HTTPS sites fail at once, this is almost certainly the cause.

Check the device time against the start date shown on the error page. On a computer, compare with a time source:

date -u

2. The certificate was issued minutes ago and your clock is slightly slow

A freshly renewed certificate is valid only from the moment of issuance. A clock that is a few minutes or hours slow rejects it until it catches up. Public TLS certificates now last at most 200 days (since 2026-03-15) and some ACME profiles issue 45-day certificates, so renewals happen more often and a slow clock meets brand-new certificates more frequently.

3. The certificate was generated on a machine with a wrong clock

Routers, NAS devices, cameras and appliances often create a self-signed certificate on first boot, before they have synced time. If their clock was ahead, the certificate starts in the future. The same happens with an internal CA server whose clock drifted. Read the dates:

openssl s_client -connect 203.0.113.10:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -startdate -enddate

4. An issuer certificate is not yet valid

A private CA created with a future date, or a new intermediate deployed before its start date, causes the ..._ISSUER_CERTIFICATE variant. Inspect each certificate in the chain with -showcerts or the certificate decoder.

Is it your device or the site?

Usually it is your device, and one comparison settles it. Open two or three large HTTPS sites you use every day. If they all fail with date-related errors, your clock is wrong and nothing on any of those sites needs fixing. If only one site fails, read the start date on its error page and compare it with the real current time in UTC. A start date hours or days ahead means the site owner issued or generated the certificate with a wrong clock, and only they can fix it.

How to fix it

Turn on automatic time sync on the device; site owners fix the server clock and reissue the certificate.

Windows: Settings > Time & language > Date & time, turn on "Set time automatically" and the time zone option, then click Sync now. From an administrator prompt:

w32tm /resync

macOS: System Settings > General > Date & Time, enable setting the time and date automatically.

Linux:

sudo timedatectl set-ntp true
timedatectl status

Android and iOS: enable automatic date and time and automatic time zone in the system settings.

Replace the motherboard battery if the clock resets after each shutdown.

Site or device owners: fix the server's time first (timedatectl, chronyc tracking), then generate or request a new certificate so that notBefore is in the past. For devices that generate their own certificates, regenerate after time sync. For a private CA, issue a new CA certificate with correct dates and redeploy the chain.

See wrong system clock SSL errors for clock problems in other browsers and apps.

How to verify the fix

date -u (or the system clock) matches real UTC time within a few seconds.
openssl x509 -noout -startdate shows a notBefore earlier than now.
Reload the page in Firefox; the warning should be gone without adding an exception. If you added an exception earlier, remove it under Settings > Privacy & Security > Certificates > View Certificates > Servers.
Check the site from outside with the SSL checker to make sure it serves a currently valid certificate.