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 with error code not_yet_valid, and the site shows Needs attention
• 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 strictly. The reassuring part: the certificate is real and signed correctly. It just isn't allowed to be used yet, so the fix is usually quick.

Common causes

• Server clock is wrong. The certificate is fine but your server's system clock is set to a time before the certificate's start date. This is the most common cause.
• The certificate was issued for a future start date. Both clocks are correct, but the certificate authority set a notBefore in the future. Some CAs let you specify a future start date; if it was set incorrectly, the cert looks "not yet valid" until that date arrives.
• You just issued and deployed the certificate within the small window where the start date hasn't propagated everywhere. This usually resolves within minutes.
• You restored an old certificate from a backup that was issued months ago and has since had its dates rewritten by a CA 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. Check your server's clock. Run:

   date -u

   Compare the output to the certificate's notBefore. If your server thinks it's earlier than that date, the clock is the problem.

3. If the server clock is wrong, fix 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.

4. If the server clock is correct but the certificate's notBefore is genuinely in the future, wait until that date is reached, or request a new certificate from your CA with a notBefore of "now".

5. If you just deployed the certificate, wait 5–10 minutes and re-check. New certificates sometimes report as not-yet-valid for a brief window while CDNs and intermediate caches update.

Worked examples

A server with the wrong clock

The SSL check is Invalid with not_yet_valid, but the certificate was issued days ago and should be fine. Check the clock against the certificate's start date:

$ date -u
Tue 12 May 2026 09:14:02 UTC

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

The server thinks it's 12 May, but the certificate doesn't start until 14 May: the clock is running two days behind. Turn on NTP and it corrects itself:

$ sudo timedatectl set-ntp true
$ date -u
Thu 14 May 2026 11:02:40 UTC

date -u is now past notBefore, so the next check shows the certificate as Valid again and the site returns to Healthy.

A certificate that genuinely starts later

Here the clock is correct: the certificate's start date really is in the future:

$ 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. If you've just issued it, wait until notBefore passes and re-check (give a freshly deployed certificate 5–10 minutes for CDN and intermediate caches to catch up). 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. The current time (date -u) should now be after notBefore.
2. Open the site in an incognito window; the padlock should appear cleanly.
3. Open the site in DomainDash. It re-checks on its normal schedule, so once the certificate validates the Security card returns to Valid and the site returns to Healthy on its own within a check cycle. There's nothing to click.

Related

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