Diagnose certificate validity time

Certificates have notBefore and notAfter timestamps, and every verification compares them against one more input people forget about: the client’s own clock. Verification uses the client’s current clock, so a wrong clock can make a perfectly valid deployment appear invalid — and a real expiry look like a mystery.

That gives you three distinct time failures that produce similar-looking errors:

• Expired: the clock is right, notAfter is in the past. Someone missed a renewal.
• Not yet valid: the clock is right, notBefore is in the future. Rare, usually a certificate issued by a machine with a fast clock.
• Clock skew: the certificate is fine, the client’s clock is wrong. Common on devices that sat powered off, containers with a broken time source, and machines without NTP.

Diagnosis means putting the two timestamps and the clock side by side. Inspect dates and current UTC time:

openssl x509 -in app.crt -noout -dates
# notBefore=Aug  3 10:45:00 2026 GMT
# notAfter=Aug 17 10:45:00 2026 GMT
date -u
# Mon Aug  3 15:02:11 UTC 2026

Use date -u and not plain date — certificate timestamps are in GMT, and comparing across timezones by eye is how off-by-a-few-hours mistakes happen. Classify the result as currently valid, expired, or not yet valid.

For a live server, take the dates from the connection itself:

openssl s_client -connect example.org:443 -servername example.org </dev/null 2>/dev/null | openssl x509 -noout -enddate
# notAfter=Jan 15 08:21:00 2027 GMT

An expired certificate also shows up in s_client as Verify return code: 10 (certificate has expired) — that code 10 is your fastest confirmation.

If the dates look sane but verification still complains about time, suspect the clock. Check whether the machine is synchronized (timedatectl on systemd Linux shows System clock synchronized: yes). A clock that is off by minutes already breaks certificates issued moments ago.

The prevention side: keep renewal monitoring ahead of the deadline. Alert when a certificate has, say, 14 days left, not when it dies. Expiry is the most predictable outage in computing — the date has been printed inside the certificate since the day it was issued.

One thing you must never do: changing the clock to hide an error breaks other security and operational systems — logs, tokens, schedulers, and every other certificate. Fix time synchronization or renew the certificate. Those are the only two real repairs.