Keys and Certs
This is some general advice on setting up keys for use with your Service Provider.
Background
Shibboleth exchanges messages using SAML. SAML uses public key cryptography to establish and maintain a trust relationship between the Service Providers and the Identity Providers. Each side will generate one (or two) private key/public cert pairs. They keep the private key to themselves. These public certs are traded between the two sides by embedding them in metadata. SAML will use these pairs for two basic operations:
Signing - One side will sign a SAML message with its private key. The other side will receive that message and use the public cert from the metadata to verify the signature. SPs may sign login requests sent to the IdP. IdPs should always sign assertion messages sent to the SP.
Encryption - One side (usually the IdP) will encrypt the SAML assertion message using the public cert for the recipient (the SP). The SP then must use its private key to decode the message. An observer will not be able to read the message without the private key.
How does this affect trust? When an SP sends a login request to an IdP, it will identify itself by its entityID. The IdP will lookup to see if it knows that SP. If the request is signed by the SP, the IdP can verify that the request is genuinely from that SP.
After the user has authenticated, the IdP will generate a SAML message to the SP. It will usually encrypt that reply so it can only be read by that SP. It will also sign the reply, so the SP can verify that it was issued by the IdP.
What is in the Metadata?
In SAML, the Metadata for an entity (SP or IdP) describes the parameters that will be used when sending messages to other entities. The two important parts of the metadata for key exchanging are:
entityID - This is the name of the SP or IdP. In a SAML message, this is passed so the recipient knows which metadata to look up to complete the transaction. entityIDs should not be changed. If they must change, then new metadata must be exchanged containing the new name and other parameters.
public key certs - These are passed as X509 certificates in the metadata. An entity can have one key pair, used for both signing and encryption. Or it can have two key pairs, one designated for signing, and the other designated for encryption.
X509 certificates are public keys that have been signed by a private key. In Shibboleth, the certificates are usually self-signed. That means the private key from the pair is used to sign the public key. Certificates also have an expiration date. Shibboleth will ignore these dates, but some other SAML providers will not. It is usually suggested to sign certificates for 5 or 10 years.
Should You Use One Key Pair or Two?
That depends primarily on whether you have an established, registered SP, or if you are setting up a new service.
An established SP should continue to use the existing key pair or pairs
You don't want to change the metadata if it is not necessary. If you are upgrading an SP with one key pair, continue to use that one key pair. Save your keys and certs before the upgrade, and be sure to restore them if they were regenerated.
In this documentation, most of our federation has established SPs with single keys, so that is the configuration that we provide by default.
A new SP should follow the recommendation to use two keys
Beginning with SP 3.0, the recommendation from the Shibboleth group is to use different key pairs for signing and encryption. As that is the new default, you should probably follow it. It is not strictly necessary for Shibboleth, but it may become important if you work with non-Shibboleth SAML identity providers.
Should you configure two key pairs, but use a single pair for both entries? You can, but that's redundant. When a single key is listed, then it is assumed to be used for both signing and encryption. You may as well use the single key configuration.