Rolling a Shared SAML Signing Certificate Across Six Service Providers
Your PingFederate 11.3 deployment is the SAML IdP for six service providers. All six SP connections currently use the same signing certificate, which expires in 30 days. Two of the SPs require encrypted assertions; one legacy SP still sends SHA-1-signed AuthnRequests and has told you it cannot accept SHA-256 responses. Metadata exchange with four SPs is manual and each has a different change-control window. You have already imported a replacement key pair and a new certificate into PingFederate, but you have not changed any connection. A test with one SP failed because that SP had not yet imported the new certificate, and its users saw signature-validation errors. The other five SPs are still working. You have about 4,000 active users and no approved maintenance window for a full outage. The business wants the rollover completed before expiry without disrupting SSO.
1. Outline a zero-downtime rollover sequence for the signing certificate. Identify the step where you would pause for external coordination and explain why.
Read the worked answer
Treat this as a trust-establishment problem, not a file-copy problem. Sequence:
- Inventory each SP's metadata contact, change window, and whether it can trust both the old and new certificate during overlap.
- Publish the new public certificate to all six SPs while PingFederate still signs with the old key.
- Confirm each SP accepts metadata that contains both certificates.
- Switch PingFederate connection signing to the new key one connection at a time, starting with a low-risk SP and not the SHA-1 SP.
- Monitor assertion validation and PingFederate logs.
- After the longest assertion lifetime plus clock skew, remove the old certificate from SP trust and from PingFederate.
Pause after step 2. You cannot switch PingFederate to the new key until every SP can validate it, and four SPs have manual, different windows. The failed test is evidence that switching before trust is in place causes outages. Do not rotate encryption certificates at the same time; encrypted assertions use a separate certificate and each SP may need both. If 30 days is too short for all six, escalate and prioritize by expiry risk, not convenience.
2. The legacy SHA-1 SP refuses to accept SHA-256 and asks you to keep signing its responses with SHA-1 after the rollover. How do you handle that request?
Read the worked answer
Do not downgrade the global signing algorithm or keep SHA-1 for all SPs. First determine whether the SP actually rejects SHA-256 or only its test harness does; ask for a SAML trace and the exact validation error. If PingFederate supports a per-connection signature algorithm, isolate SHA-1 to that one connection and require security to sign a time-bound risk acceptance. If per-connection control is not available, the options are a separate IdP connection or endpoint for that SP, if the platform permits it, or requiring the SP to upgrade before the rollover date. The certificate rollover and the algorithm choice are separate decisions: you can rotate the key and still sign SHA-1 for one SP only if the platform allows it. Do not let one legacy SP block the other five. If the SP cannot support SHA-256 and will not accept the risk, the business must accept that SSO to that SP stops at certificate expiry.