Spring SAML certificate rollover: overlap trust without accepting unknown keys

A new certificate is a planned change

The identity provider announces a signing-key rotation. The relying party verifies SAML signatures against configured trusted credentials. If the old key disappears before the app recognizes the new one, login fails; if every key from newly fetched unsigned metadata is accepted, trust can be widened without review. Signature validation remains mandatory throughout the rollout.

Stage, observe, remove

Validate the new certificate's identity through an agreed channel, add it alongside the still-valid old key for the overlap window, and observe which key signs actual assertions. Remove the old credential after the IdP completes rotation and the maximum in-flight login window passes. Keep the registration-specific trust set separate for every IdP.

Test a forged and an old response

A signed response using the planned new key should work during overlap; a response signed by an unrelated key must fail. After old-key removal, the old response must fail too. Run the check through the production proxy and actual metadata endpoint so an issuer or ACS mismatch is visible.

Implementation sketch

// Trust-store rollout invariant:
// before: {currentKey}
// overlap: {currentKey, nextKey}
// after: {nextKey}
// Never accept an assertion merely because its XML carries a key.

Cost and verification

Overlapping trusted keys temporarily widen the accepted signing set. Bound that window, audit its start and end, and avoid a login outage from an uncoordinated cutover.

Common Mistakes

• Do not disable signature verification during rotation.
• Do not trust an assertion's embedded certificate without registration policy.
• Do not leave a retired IdP key trusted indefinitely.

Read next

Spring Security SAML validation: signatures, audience and clock window, Spring Security SAML relying party: align registration, ACS and metadata, Spring Security SAML logout: local session versus single logout.