...
To increase the chances of your deployment interoperating:
- If the certificate will be used for TLS/SSL server authentication (e.g., an IdP's SOAP endpoint), make sure your certificate's CN (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.
- For key management, InCommon allows multiple certificates per end point at any time. You can log in to the site administration tool, select the particular endpoint, then choose the one or more certificates you want to associate with this endpoint. This is helpful for migrating from one certificate to another during a finite period of time.
- However, bear in mind that not every SAML implementation supports multiple keys properly and you may want to test this with any non-Shibboleth partners. For example, EZProxy supports metadata, but is known to ignore additional keys beyond the first.
- For those using the Shibboleth SP, the self-signed certificate generated during installation of the software (or subsequently using the keygen shell/batch script) is generally suitable for use within the federation.
InCommon No Longer Issues Certificates (as of January 2010)
...