...
A SAML entity uses public key cryptography to secure the data transmitted to trusted partners. Public keys are published in the form of X.509 certificates in metadata whereas the corresponding private keys are held securely by the entity. These keys are used for message-level signing and encryption, and to create secure back channels for transporting SAML messages over SSL/TLS.
| Info | ||
|---|---|---|
| ||
In addition to message-level signing and encryption, X.509 certificates in metadata are used for SSL/TLS back-channel SOAP exchanges, typically on a nonstandard port such as 8443. These certificates are not the same as and have nothing to do with SSL/TLS certificates used for browser-facing transactions over port 443. The latter type of SSL/TLS certificates are not contained in metadata. |
...
- 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 the OIOSAML Java SP) and with some versions of Apache used in the deployment of 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 in to the site administration tool, 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 entities 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 SSL/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.
...
| title | Recognizing an SSL/TLS Key |
|---|
...
- .
Obtaining a Self-signed Certificate
...