...
The certificate is communicated via a <md:KeyDescriptor use="signing"> element in SAML metadata. The use XML attribute is important, as will be made clear below.
In a new install of V4 or an upgrade from V3 or laterUnless upgrading from V2, the generated signing key pair will be prefixed idp-signing (the names can be overridden if desired via the idp.properties file).
...
The older practice of using the same key for both digital signing and back-channel TLS is obviously permitted but is discouraged to limit key usage to specific purposes, which is a more secure practice. In particular, there are many more known attacks in recent years that have compromised TLS server keys than on keys used "behind the scenes".
In a new install, or upgrade of a V3+ install, Unless upgrading from V2, the generated back-channel key pair will be prefixed idp-backchannel but the files are not explicitly referenced by the IdP configuration because they are meant for use by the container to configure its back-channel TLS connector/listener.
In V2, the back-channel key pair was also not part of the configuration but conventionally was the same as the signing key pair. An upgraded install of to V3 did not generate a new key pair and was generally assumed to be reusing the existing back-channel configuration choices.
...
A third key pair, new to V3 and subsequent versions of the IdP, supports inbound XML Encryption. The private key is used to decrypt data encrypted under the public key. The latter is bound to a certificate that is communicated via a <md:KeyDescriptor use="encryption"> element in SAML metadata.There
The primary value of an encryption key to an IdP is when operating as a proxy (i.e., acting as an SP), so the key is used to decrypt encrypted Assertions issued to it.
Outside of proxying, there are only a few scenarios in which SPs are likely to need to encrypt data transmitted to the IdP and none of them are common or essential. The most likely use case would be to encrypt the subject of a SAML logout request but Shibboleth SPs (and most other implementations) don't do this by default.
...
Note that advertising a certificate in metadata with no use XML attribute is an indication that the same private key is used for both signing and decryption. After an upgrade, you may have older IdP metadata needing correction that mistakenly indicates this.
In a new install, or upgrade of a V3+ install, Unless upgrading from V2, the generated encryption key pair will be prefixed idp-encryption (the names can be overridden if desired via the idp.properties file).
In V2, this functionality did not exist and so no allowance for this existed in the configuration. An upgraded install of V3 deferred upgrade from V2 defers the timing of having such a key pair and some adjustments had would have to be made at some point later on. An upgrade using a clean install, and using the generated key pair, requires adjusting your IdP's metadata shared with every SP to reflect the use of a separate key pair for this function, as noted above. Doing this while publishing metadata containing a certificate in metadata with no use XML attribute will cause problems.
...