Self-Healing CI: Recovering When a TLS Cert Chain Is Temporarily Unavailable
A TLS verification that fails because an intermediate or revocation responder was briefly unreachable hit a transient blip, not an invalid certificate -- the same handshake verifies on a retry.
The problem
A request fails TLS verification because part of the certificate chain (an intermediate fetched via AIA) or a revocation responder (OCSP/CRL) was temporarily unreachable. The certificate is valid and not revoked; a momentary blip prevented the chain or revocation check from completing. A human re-runs and the handshake verifies cleanly.
SSL certificate problem: unable to get local issuer certificate
OCSP responder timed out; revocation status unknownWhy it happens
Completing a TLS verification can require fetching an intermediate certificate or contacting a revocation responder over the network, so if that responder or intermediate source is briefly unreachable, verification can fail even though the certificate itself is valid and unrevoked.
It is a transient availability blip in the verification path, not an invalid certificate: the same handshake verifies once the chain/revocation fetch is retried and succeeds.
The manual fix
Manual mitigations for a temporarily-unavailable chain:
- Re-run the job to retry the request and verification.
- Bundle the full chain (include intermediates) so AIA fetching is not required.
- Add retry-with-backoff around requests sensitive to revocation/intermediate fetches.
How this gets automated
A temporarily-unavailable chain or responder has a recognizable transient signature -- a fetch/timeout failure in the verification path rather than an explicitly invalid or revoked certificate -- and the safe response is to retry. A self-healing CI pipeline detects the verification failure, retries with backoff, and only escalates if verification keeps failing, which is the real signal of a genuinely invalid certificate rather than a momentary chain blip.