This article discusses the use of X.509 certificates in Federation metadata.
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.
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. |
The use of long-lived, self-signed certificates in InCommon Federation metadata is strongly recommended. Certificates signed by a Certification Authority (CA) are allowed, and in most situations will work just fine, but the use of certificates other than self-signed certificates is discouraged. See the Background information and the Interoperability notes below for further discussion.
|
Any certificates you want to use with your SAML software are uploaded via the administrative interface. Typically only one certificate is required but multiple certificates may be uploaded and used as needed. For instance, multiple certificates may be used to facilitate the controlled rollover of expired certificates. For detailed guidelines on the rollover process, refer to the Certificate Migration topic.
In the base SAML metadata specification \[1\], a certificate signing authority (CA) has no assumed relevance to the trust model that secures the interactions among a federation's participants. In fact, certificates signed by a CA are discouraged since they can create interoperability issues in certain situations and lead to configurations that mistakenly establish trust based on the certificate signer. Allowing self-signed certificates simplifies the work of participants who may be required to join multiple federations, or who support local systems that are not enrolled in the Federation. |
InCommon conforms to the _SAML V2.0 Metadata Interoperability Profile_ \[2\] from OASIS. Participant site administrators securely transmit X.509 certificates and metadata to InCommon. InCommon signs the entire metadata file, securing the keys of its participants whether those keys are bound to self-signed certificates or certificates signed by a CA. The critical element in the certificate is the public key, which is associated with the participant's "entityID." The other elements in the certificate are irrelevant for security and trust processing. Theoretically, if all the relevant software systems could accept a public key without a certificate wrapper, InCommon would only need to include the public key of each endpoint. As it is, the certificate is a practical shell for the public key, the critical element being that the key is bound to a particular entity in the metadata. |
InCommon sets the following security and trust requirements around certificates included in Federation metadata:
Consider the following interoperability issues as you set up and maintain your deployment:
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. |
<md:EntityDescriptor>
element containing more than one encryption key.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.
The self-signed certificate generated during the installation of the Shibboleth IdP may be suitable if the hostname it deduces matches the one you expect to publish in your metadata. This will often not be the case, so use caution.
Use the following command to generate a long-lived, self-signed certificate with OpenSSL:
openssl req -new -x509 -days 3650 -keyout key.pem -out cert.pem -newkey rsa:2048 -subj "/CN=hostname.example.org" |
\[1\] _Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0_ [http://saml.xml.org/saml-specifications] \[2\] _SAML V2.0 Metadata Interoperability Profile_ [http://wiki.oasis-open.org/security/SAML2MetadataIOP] \[3\] [X.509 Certificates in the Federation Metadata|http://internet2.na6.acrobat.com/p46467886/]: A technical webinar presented by the _InCommon Technical Advisory Committee_ (October 22, 2009) \[4\] _The Shibboleth ExplicitKey Trust Engine_ [https://spaces.at.internet2.edu/display/SHIB2/ExplicitKeyTrustEngine] |