SAML deployments depend on a shared understanding of signing certificates and trust metadata. If an identity provider begins signing with a certificate that a service provider does not yet trust, a correct rotation can break login for every user who depends on that connection.
Separate trust update from cutover
Rotation has at least two distinct events: distributing the future certificate and beginning to use it. Where the protocol and implementation allow it, trust the new certificate before switching the active signer. That creates an overlap window in which both current and next trust configurations can be validated.
WebFrolic’s product notes describe a secondary-certificate fallback intended to rotate the primary certificate without an outage. Treat it as a configuration to test, not an assumption. Confirm which certificate signs assertions, which certificates are accepted and what happens when metadata is stale.
Make metadata and ownership visible
Record the certificate fingerprint, issuer, validity interval, active/secondary status and systems that depend on it. Assign an owner and reminder well before expiry. A certificate with no clear owner tends to be rotated at the last minute, when there is least time to test.
Use a controlled metadata exchange process where appropriate and compare received values with the intended trust configuration. Keep private keys protected and separate from the public certificate distribution path.
Test normal and failure paths
In a test environment, simulate the new signer becoming active while the relying party still has old metadata, then update the relying party and verify login. Test invalid signatures, expired certificates and unexpected signers so the system fails closed with useful diagnostics.
Define rollback conditions in advance. If cutover fails, know who can restore the previous signer, which state must be reverted and how to confirm trust. Keep the fallback window bounded and remove obsolete trust when it is no longer required.
Treat rotation as an audited change
Record who changed the certificate configuration, when the new value was added, when the active signer changed and what validation was performed. This history helps distinguish an operational mistake from suspected key compromise.
If the rotation responds to a possible compromise rather than routine expiry, the response may require faster trust changes and broader investigation. Do not use the ordinary maintenance playbook without reviewing its assumptions.
Put it into practice
Audit it like this
- Track certificate ownership, expiry and dependent connections.
- Pre-stage and validate the replacement certificate where supported.
- Test stale metadata, invalid signatures and rollback behaviour.
- Remove obsolete trust after the overlap window and audit the change.