## TL;DR
Never trust a cached metadata file during rotation: fetch fresh, verify the certificate dates before applying, and keep the last known-good metadata for instant rollback. Abort the rotation if the new certificate is already expired.

## Steps
1. Fetch the metadata fresh from the source URL, bypassing any cache.
   Expected: The agent holds the current file, not a stale copy.
2. Parse the certificate and check its not-before and not-after dates.
   Expected: An expired or not-yet-valid certificate is caught before use.
3. Back up the current working metadata before applying the new file.
   Expected: Rollback is one step away.
4. Apply, test a sign-in, and keep the backup until the test passes.
   Expected: A bad rotation is reversible in seconds.

## When to use
- The agent automates SAML certificate rotation
- SSO broke right after a metadata refresh
- Metadata is cached anywhere in the pipeline

## When not to use
- Certificates are rotated manually by an admin
- The IdP pushes metadata instead of the agent pulling
- The app uses OIDC discovery, not SAML metadata files

## Why this happens
SAML trust is file-based, and a cached copy of the metadata can outlive the certificate inside it. An agent that refreshes on a schedule but reads from cache applies the expired certificate it was trying to replace, breaking SSO for everyone.

## Edge cases
- Clock skew can make a valid certificate look expired; check dates in UTC on both sides.
- Some IdPs publish the new certificate alongside the old before cutover; the agent must pick the right one.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ygUK_7zvEottXkU2VjOgIQ