The use of self-signed certificates in Federation metadata is strongly RECOMMENDED. Certificates signed by a Certificate Authority (CA) are allowed, and in most situations will work just fine, but the use of such certificates is discouraged. See the Interoperability notes and the Backgrounder information below for further discussion.
As of January 2010, InCommon does not issue certificates signed by the InCommon CA. We will transition the entire federation to self-signed certificates by the end of 2012. |
InCommon sets the following security and trust parameters around certificates that are included in Federation metadata:
To increase the chances of your deployment interoperating:
<md:KeyDescriptor>
element in metadata that has either a use="signing"
attribute or no use
attribute whatsoever is understood to be used for TLS/SSL.keygen
shell/batch script) is generally suitable for use within the federation.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. Certificates signed by a CA are discouraged since they can create interoperability issues in certain cases and lead to configurations that mistakenly rely on the certificate signer to establish trust. 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. |
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 they are represented in the context of self-signed certificates or certificates signed by an authority. 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 end point. 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.
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, but this depends on your need for a TLS/SSL certificate and whether the hostname it deduces matches the one you expect to publish in your metadata. This will often not be the case, so use caution.
If you need to generate your own, an example of doing so using OpenSSL follows:
openssl req -new -x509 -days 1095 -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) |