## TL;DR
Rotate without downtime by publishing BOTH certificates during a transition window: add the new signing certificate to the identity provider first, update the app to trust both, then remove the old certificate after traffic is flowing on the new one. Most outages come from replacing the certificate in one step, which invalidates every login the app expects to be signed with the old cert.

## The error
```text
SAML response signature validation failed: certificate does not match
```
```text
Your SAML signing certificate expires in 30 days
```

## Steps
1. Generate the new certificate in the IdP: in Okta, Applications > the app > Sign On > SAML Signing Certificates > Generate new certificate; in Entra ID, Enterprise apps > the app > Single sign-on > SAML Certificates > Create new certificate. Expected: a new cert with a fresh expiry appears alongside the old one.
2. Download the new federation metadata XML or certificate and upload it to the application (service provider). Expected: the app now trusts both the old and new certificates. This is the step people skip, and skipping it is what causes downtime.
3. Switch the IdP to sign with the new certificate: in Okta set the new cert as active; in Entra ID activate the new certificate. Expected: new SAML responses carry the new signature while the old cert stays published for validation.
4. Verify logins work: have a test user sign in, and check the IdP sign-in logs for successful SAML authentications. Expected: successes, no signature errors.
5. After the overlap window (24 to 48 hours is typical), remove the old certificate from the app and the IdP. Expected: only the new cert remains, logins still work.
6. Set a calendar reminder or alert 60 days before the new expiry. Expected: the next rotation is planned, not an incident.

## Use this when
- An IdP dashboard warns a SAML signing certificate is expiring soon
- You must change a signing certificate used by production SSO
- Migrating from self-signed to CA-issued signing certificates

## Not for this skill when
- The expiring certificate is a TLS/HTTPS certificate on a web server (different rotation flow)
- Rotating OAuth or OIDC client secrets (not SAML signing)
- The certificate already expired and SSO is down (use the emergency path in Variants first)

## Compatibility
- Okta, Microsoft Entra ID, Google Workspace, Auth0, any SAML 2.0 IdP/SP pair
- SAML 2.0 HTTP-Redirect and HTTP-POST bindings

## Variants
### Certificate already expired and SSO is down now
Do an emergency same-day rotation: generate the new cert, update the app metadata, and activate immediately, then tell users to retry. Expired SAML certs do not break existing sessions, only new logins, so the blast radius is limited to fresh sign-ins.
### Multiple apps share one certificate
Rotate the IdP cert once, then update every app's metadata. Track which apps pin the cert versus reading metadata from a URL; URL-based apps pick up the new cert automatically.

## Why it happens
The app validates the IdP's signature against a pinned certificate. If the IdP starts signing with a cert the app does not know, every new login fails validation. Publishing both certificates during the cutover means the app accepts signatures from either, so old and new responses both verify.

## Edge cases
- Some service providers accept only ONE signing certificate at a time; for those, cut over in a maintenance window instead.
- Certificate activation in Entra ID can take up to an hour to propagate; do not remove the old cert in the same hour.
- Long-lived sessions are unaffected; only new authentications use the new signature.

## Provenance

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