Certificate not yet valid

Your SSL certificate has a start date that hasn't been reached yet. Browsers reject certificates that aren't active, so visitors see the same warning as for an expired certificate.

Symptom

• DomainDash marks the SSL check as Invalid and the site shows a Security problem badge. The Security card reads "Your certificate isn't active yet — it's set to start in the future, so browsers won't trust it right now."
• Visitors see a browser warning page (often the same NET::ERR_CERT_DATE_INVALID as for expired certificates)
• Running openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates shows a notBefore date in the future

What it means

Every SSL certificate has both a start date (notBefore) and an end date (notAfter). A certificate isn't valid until its start date is reached, and browsers enforce this. The certificate itself is real and signed correctly. It can't be used before that date.

Whoever checks the certificate compares those dates with their own clock. A visitor's browser uses the visitor's device clock, and DomainDash uses its checker's clock. Your web server's clock plays no part. When DomainDash reports this issue, the certificate's start date is in the future.

Common causes

• The certificate was issued with a start date in the future. Some CAs let you pre-issue a certificate or schedule its start date. Until that date arrives, every visitor sees the warning.
• The certificate was generated on a machine whose clock was ahead. A self-signed or internal-CA certificate takes its notBefore from the clock of the machine that generates it.
• One visitor's device clock is set in the past. Only that visitor sees the warning, and DomainDash doesn't report it.

A wrong clock on your web server doesn't change how visitors judge the certificate, though it can break automated renewal.

How to fix

1. Check the certificate's dates. Run:

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

   Note the notBefore value.

2. Compare it with the current time. On a machine whose clock you trust, run:

   date -u

   If notBefore is later than the output, the start date is in the future for every visitor: go to step 3 or 4. If notBefore has already passed, the certificate is fine: go to step 5.

3. If a CA issued the certificate, wait until that date is reached, or request a new certificate from your CA with a notBefore of "now".

4. If you generated the certificate yourself (self-signed or internal CA), correct the clock on the machine that generated it. On most Linux servers, ensure NTP is running:

   sudo timedatectl set-ntp true
   sudo systemctl restart systemd-timesyncd

   The clock should sync within a minute. Run date -u again to confirm, then generate the certificate again.

5. If only one visitor sees the warning, ask them to correct the date and time on their device.

Worked examples

A certificate generated on a machine with the wrong clock

You generated a self-signed certificate today, 14 May, and DomainDash says it isn't valid yet. Check the clock on the machine that generated it against the certificate's start date:

$ date -u
Sat 16 May 2026 09:20:31 UTC

$ openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates
notBefore=May 16 09:14:02 2026 GMT
notAfter=Aug 14 09:14:02 2026 GMT

The machine thinks it's 16 May, so it stamped the certificate with a start date two days ahead. Turn on NTP and the clock corrects itself:

$ sudo timedatectl set-ntp true
$ date -u
Thu 14 May 2026 09:21:05 UTC

Generate the certificate again. Its notBefore is now in the past, so the next SSL check no longer reports it as not yet valid.

A certificate that starts later

Here the current time, read from a clock you trust, is before the certificate's start date:

$ date -u
Thu 14 May 2026 11:30:00 UTC

$ openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates
notBefore=May 14 12:00:00 2026 GMT
notAfter=Aug 12 23:59:59 2026 GMT

The certificate doesn't start for another half hour. Wait until notBefore passes and re-check. If you need it live right now, reissue it with a notBefore of "now".

How to verify

1. Re-run the OpenSSL check from step 1. notBefore should now be earlier than the current time (date -u).
2. Open the site in an incognito window. For a certificate from a trusted CA, the padlock should appear with no warnings.
3. Open the site in DomainDash. The next scheduled SSL check (every 6 to 24 hours, depending on your plan) clears the "not yet valid" reason. If the problem had also taken the site Down, DomainDash re-checks the certificate as soon as the site recovers, so this happens within minutes. A certificate from a trusted CA then shows as Valid and the Security problem badge clears. A self-signed certificate keeps the badge and shows the self-signed reason until you replace it with one from a trusted CA: see Self-signed certificate.

Related

• Certificate expired — the inverse problem (end date in the past)
• TLS handshake failed — generic TLS issues
• SSL certificates — how DomainDash checks SSL