Self-Healing CI: Recovering a Clock-Skew TLS Validation Failure
When TLS validation rejects a perfectly good certificate, suspect the runner’s clock -- a skewed time makes a valid cert look outside its validity window, and a time sync fixes it.
The problem
A TLS connection fails validation against a certificate that is actually valid, because the runner’s clock is skewed -- so the cert appears to fall outside its validity window. The certificate and endpoint are fine; the system time is wrong. A human re-syncs the clock or re-runs on a correctly-timed runner and validation succeeds unchanged.
x509: certificate has expired or is not yet valid: current time ... is outside validity period
# the runner clock was skewed; the certificate itself is validWhy it happens
TLS validation checks a certificate’s validity window against the local system clock. If the runner’s time has drifted or was not synced after a fresh boot, a valid certificate can appear expired or not-yet-valid purely because the clock is wrong.
The certificate is correct; the time is not. Once the runner’s clock is corrected via a time sync, the same validation passes with no change to the cert or the endpoint.
The manual fix
The manual fix is to correct the clock and retry:
- Compare the runner’s time to a trusted source to confirm the skew.
- Force a time sync (NTP) so the clock is accurate.
- Re-run the step -- validation now uses the correct current time.
date -u
sudo chronyc makestep || sudo ntpdate -u pool.ntp.org
date -uHow this gets automated
A clock-skew validation failure has a recognizable signature -- a validity-window error against a known-good cert -- and a well-defined remedy: correct the time and retry. A self-healing CI pipeline detects the skew-driven failure, corrects the runner’s clock, retries the step, and only escalates if the certificate is genuinely outside its window after the clock is right.