Page History

...

• A potential federation partner (especially sponsored partners) may question the use of self-signed certificates. As discussed in the Background section, there are no interoperability issues with self-signed certificates. Indeed, just the opposite is true.
• The Shibboleth software does not check the expiration dates of certificates, but this practice often causes interoperability issues with other software, and with some older (generally now unsupported) versions of Apache used in the deployment of the Shibboleth IdP.
  • Note: You may continue using an expired certificate in Federation metadata if necessary. InCommon recommends that you plan ahead and migrate to an unexpired certificate well ahead of your certificate's expiration date.
• For key management purposes, InCommon allows multiple certificates per endpoint at any time. You can log in to the site administration tool, select a particular endpoint, and associate one or more certificates with that endpoint. This is helpful for migrating from one certificate to another during a finite period of time.
• Bear in mind that some SAML implementations do not support multiple keys properly and you may want to test this with your non-Shibboleth partners. For example, EZProxy supports metadata, but is known to ignore additional keys beyond the first.
• If the certificate will be used for TLS/SSL server authentication (e.g., an IdP's SOAP endpoint), make sure your certificate's CN (and/or subjectAltName) value matches the intended hostname. This will maximize the chances that your implementation will work. This TLS/SSL configuration is left to your discretion and responsibility. InCommon highlights this point as one that may likely cause problems if not met.
  • Note: Any <md:KeyDescriptor> element in metadata that has a use="signing" attribute or no use attribute whatsoever is understood to be used for TLS/SSL.

...