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 Down with error code not_yet_valid
• 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. This error means the certificate is real and signed correctly — it just isn't allowed to be used yet.

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.
• DomainDash's checker clock is right and yours is right but the cert was issued for a future date. Some certificate authorities allow specifying a future start date; if this was set incorrectly the cert will look "not yet valid" until that date.
• 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.

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. Click "Check now" in DomainDash. Status should flip to Healthy.

Related

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