SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
TLS New Added 8 September 2026

TLS: certificate is not yet valid

The certificate's notBefore date is in the future according to the client. The certificate is almost always fine: the client's clock is wrong, which is common on containers without a time source, embedded devices with no battery, and virtual machines resumed from a snapshot.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Compare the two
openssl s_client -connect host:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -dates
date -u

# Fix the clock, not the verification
sudo timedatectl set-ntp true
chronyc makestep

# Containers inherit the host clock: fix the host
docker run --rm alpine date -u

# Genuinely early certificate: some CAs backdate by an hour, so
# a freshly issued one can be rejected by a fast clock. Wait, or reissue.

How to diagnose TLS errors

TLS errors have a small number of root causes: the certificate is expired, the hostname does not match any SAN entry, the chain is incomplete (the server did not send its intermediates), the issuing CA is not trusted by this client, or the two sides share no cipher or protocol version. The incomplete-chain case is the most deceptive, because browsers often paper over it with cached intermediates while curl, Java and Go fail.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Inspect the live handshake: openssl s_client -connect host:443 -servername host -showcerts. It shows the full chain the server actually sends.
  2. Check dates and SANs: openssl x509 -noout -dates -subject -ext subjectAltName. The Common Name is ignored by modern clients: only SANs matter.
  3. If browsers work but curl or your language runtime does not, suspect a missing intermediate. Browsers cache intermediates; other clients do not.
  4. Verify the trust store the failing client uses. Containers frequently ship without ca-certificates installed, and Java, Node and Python each have their own store.
  5. For protocol or cipher errors, check the negotiated version and the server's supported list. TLS 1.0 and 1.1 are disabled by default in current clients.

Tools worth reaching for

  • openssl s_client
  • openssl x509 -noout -text
  • curl -vI
  • testssl.sh
  • sslyze

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

rfc-editor.org

Related TLS errors

See all 24 TLS errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.