TLS "certificate has expired" in CI
The client validated the certificate dates and found the current time is past the certificate notAfter, so it rejects the connection. Either the server certificate genuinely lapsed, or the runner clock is skewed enough that a valid certificate appears expired.
What this error means
curl or a language client fails with "certificate has expired" or "certificate is not yet valid". OpenSSL reports "verify error:num=10:certificate has expired".
curl: (60) SSL certificate problem: certificate has expired
* SSL certificate verify result: certificate has expired (10)Common causes
The server or intermediate certificate lapsed
A certificate or one of its intermediates passed its expiry date and was not renewed, so the chain is no longer valid.
The runner clock is wrong
A container or VM with a badly skewed clock computes the wrong "now", making a currently valid certificate look expired or not yet valid.
How to fix it
Check the certificate dates and the clock
- Print the certificate validity window for the host.
- Compare it against the runner's current time.
- If the clock is skewed, correct time sync; if the certificate lapsed, it must be renewed server side.
echo | openssl s_client -connect api.example.com:443 2>/dev/null \
| openssl x509 -noout -dates
date -uRenew the expired certificate
If the certificate itself lapsed, the endpoint owner must reissue it; the client cannot work around a genuinely expired certificate without disabling verification, which is unsafe.
How to prevent it
- Monitor certificate expiry for endpoints CI depends on.
- Keep runner clocks synced so validity windows are computed correctly.
- Automate renewal for internal certificates well before expiry.