Certificate Expiry Across Large Fleet

A large fleet of TLS certificates, spanning Modern, Critical, and Legacy cohorts with genuinely different rotation capability, rollout speed, and dependency risk, is approaching a shared expiry deadline across the Certificate Authority, Secret Distribution, Service Fleet, Load Balancers, and External Clients. Live connection success stays perfectly healthy for days of simulated calendar time while the deadline clock runs down — this is a proactive, calendar-driven remediation, not an external failure. Five business invariants govern every decision: (1) the Critical cohort may never cross the expiry deadline un-rotated; (2) new certificates must be verifiably installed before old certificates are withdrawn; (3) Legacy cohorts may require a temporary overlap bridge, because their dependency chain updates its trust bundle more slowly than Modern or Critical; (4) broad validation bypass is not acceptable, however urgently it would restore connectivity; (5) deadline risk must be explicitly tracked by cohort, never averaged into one fleet-wide number that could hide which specific cohort is actually at risk. The scenario's defining lesson is sequencing, not merely speed: the SAME eventual configuration — trust bundle updated, old certificate eventually revoked — is only safe when reached in the correct order. Revoking the old certificate before the Legacy cohort's trust bundle is verified breaks every Legacy client, even though both the revocation and the trust-bundle update eventually happen in the same timeline. Decide which cohort to rotate first, how to stage and verify each cohort's new certificate before withdrawing the old one, whether Legacy needs its own extended bridge, and — when a premature gap is ever created — whether to close it the deliberate, auditable way or reach for the tempting but forbidden broad validation bypass.

Difficulty

Senior Staff

Expected Time

~25 min

Category

Security & Identity