...
- The use of long-lived, self-signed certificates in Federation metadata is strongly RECOMMENDED.
- Certificates with lifetimes of at least 10 years are RECOMMENDED to avoid unnecessary technically-imposed deadlines on key rollover.
- Certificates SHOULD expire before 2038 to avoid the so-called Year 2038 problem.
- RSA keys with a minimum size of 2048 bits MUST be used for all new certificates introduced into Federation metadata.
- New certificates with keys key sizes less than 2048 bits are not allowed in Federation metadata.
- Certificates with keys greater than 2048 bits are NOT RECOMMENDED since such keys require force relying parties to perform unnecessary computation.
- Expired certificates SHOULD NOT be introduced into Federation metadata. An expired certificate in metadata SHOULD be removed once a certificate migration process to a new certificate has been completed.
- A certificate's expiration date has nothing to do with the security of the corresponding private key, which is an ongoing concern.
- If a private key is lost or stolen, immediate steps MUST be taken to configure a new private key MUST be configured immediately and to introduce the corresponding public key certificate MUST be introduced into metadata. Since there are no other known attacks on RSA 2048-bit keys, generating a new private key for any other purpose is NOT RECOMMENDED.
- Service providers MUST include an encryption key in SP metadata.
- The encryption key is used by IdPs to encrypt SAML V2.0 assertions transmitted to the SP.
- InCommon does not validate Subject information in self-signed certificates because this information is irrelevant from a security perspective. However, at its discretion, InCommon will reject metadata submissions if that submission contains a certificate with fields that contain egregiously misrepresented Subject information as decided by InCommon on a case-by-case basis. Generally, Subject information should express a somewhat reasonable relationship between the certificate and the organization.
...
- A potential federation partner (especially a partner not using the Shibboleth software) may question the use of self-signed certificates. As discussed in the Background section, there are, in fact, fewer interoperability issues with self-signed certificates compared to CA-signed certificates.
Wiki Markup The Shibboleth software does not check the expiration dates of certificates \[4\], but *expired certificates often cause interoperability issues* with other software (such as AD FS 2.0 and the OIOSAML Java SP) and with older versions of Apache used in the deployment ofto deploy the Shibboleth IdP. InCommon recommends that you plan ahead and [migrate to an unexpired certificate|Certificate Migration] well ahead of your certificate's expiration date.
- For key management purposes, InCommon allows multiple certificates per role descriptor at any time. (You can log into the administrative interface, select a particular role, and associate more than one certificate with that role for the purposes of migrating from one certificate to another.) Bear in mind, however, that some SAML implementations do not support multiple keys properly and you may want to test this capability with your non-Shibboleth partners. For example:
- EZProxy is known to ignore additional keys beyond the first.
- AD FS 2.0 will not consume an
<md:EntityDescriptor>element containing more than one encryption key.
- At the deployer's convenience, a single certificate may be bound to multiple SPs in InCommon metadata. However, some implementations (e.g., AD FS 2.0) do not allow the same certificate to be used by two distinct entities.
- If the certificate will be used for TLS server authentication, the certificate's CN (and/or subjectAltName) value should match the server's hostname. This is especially true for IdPs but may also be true in certain advanced scenarios where the SP acts as a SOAP responder.
- Avoid certificates with special certificate extensions, since some implementations will actually try to use them. For example, AD FS 2.0 will attempt to access the CRL at the location given in the CRL Distribution Point certificate extension.
...