SAML2 Metadata - Multiple Signing Certificates

When the IDP is changing it's signing certificates it first publishes the new certificate in parallell with the old certificate in the metadata. When the idp actually switches over to using the new certificate, all SPs must know of the new certificate, or they will not be able to validate the signatures.

As an SP you have no idea of where in the process the IDP is, so you have to check if the signature validates to any of the two listed certificates.

Another reason you might (always) see two is that you might have one coming from a backchannel certificate (eg. credentials/idp-backchannel.crt and credentials/idp-signing.crt)

I think there are many SPs that don't really know what to do there. If you don't need backchannel, you might consider removing it (or at least not handing it to people in your curated metadata).

The annoying (really annoying) thing in my experience is that all three are separate certificates about the same thing (at least in my case), and all three are valid at the same time (this will surely lead to difficulties).

As per https://wiki.shibboleth.net/confluence/display/IDP30/Installation :

The installation process will suggest or generate the following information for you:

(begin quote)

• the IdP's entityID (which you can override as noted above)
• separate self-signed key/certificate pairs for:
  • message signing
  • securing web service connections, generally on port 8443
  • encryption of data by other systems for decryption by the IdP
• a secret key and key version file for securing cookies and other data produced by the IdP for its own use (this is a special Java keystore of type "JCEKS")
• some initial sample metadata describing the IdP for use by partner SPs, once it's reviewed and supplemented
• a default set of IdP configuration files based on this information

(end quote)