agent's sso metadata refresh pulled the expired certificate: cache invalidation
This skill fixes a helpdesk agent that refreshes SAML metadata and ends up trusting an expired certificate because it cached the old file. It shows how to validate freshness and roll back. For agents that automate SAML certificate rotation.
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
Fetch the metadata fresh from the source URL, bypassing any cache. Expected: The agent holds the current file, not a stale copy.
Parse the certificate and check its not-before and not-after dates. Expected: An expired or not-yet-valid certificate is caught before use.
Back up the current working metadata before applying the new file. Expected: Rollback is one step away.
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/pstygUK7zvEottXkU2VjOgIQ