X.509 Certificates in Metadata

X.509 Certificates in the InCommon Federation

The use of self-signed certificates in InCommon 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 certificates other than self-signed certificates is discouraged. See the Background information and the Interoperability notes below for further discussion.

Background

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.

Requirements

InCommon sets the following security and trust parameters around certificates that are included in Federation metadata:

• The use of self-signed certificates in Federation metadata is strongly RECOMMENDED.
• RSA keys with a minimum size of 2048 bits must be used for all new certificates introduced into Federation metadata.
• Certificates with keys less than 2048 bits will not be allowed in Federation metadata.
  • All participants must migrate old 1024-bit keys out of metadata and upgrade to 2048-bit keys by December 2012.
• We recommend that participants submit a new certificate with a new 2048-bit key every 3 years.
• Expired certificates should not be introduced into Federation metadata.

• A certificate in metadata that expires should be removed once the rollover process to a new key has been completed. See [2] and the section on Key Rollover below.

• InCommon does not validate Subject information in self-signed certificates because this information is irrelevant to the federated security context. However, at its own discretion, InCommon will reject metadata submissions if that submission contains a certificate with fields that contain egregiously misrepresented Subject information as decided by InCommon on a case by case basis. Generally, subject information should express a somewhat reasonable relationship between the certificate and your organization.

Interoperability

Consider the following interoperability issues as you set up and maintain your deployment:

• 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.

• The Shibboleth software does not check the expiration dates of certificates [4], but expired certificates often cause interoperability issues with other software 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 well ahead of your certificate's expiration date. See the section on Key Rollover below.

• 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.
• Some implementations (e.g., AD FS 2.0) do not allow the same certificate to be used by two different entities.
• If the certificate will be used for TLS/SSL 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.

Key Rollover

For a certificate about to expire in metadata, the following key rollover process is recommended:

1. InCommon notifies a participant site at least 30 days before a certificate in metadata will expire.
2. The site admin uploads a new (unexpired) certificate.
3. The site admin binds the new certificate to the role descriptor(s) in metadata that contain the expired certificate.
4. After waiting at least three (3) weeks, the site admin configures the software to use the new certificate and then removes the expired certificate from metadata.

Be sure to cover all instances of the expired certificate at step 3. In particular, an IdP often uses the same certificate for both the <md:IDPSSODescriptor> and <md:AttributeAuthorityDescriptor> roles. If that certificate expires, both <md:KeyDescriptor> elements containing the expired certificate need to be transitioned to the new (unexpired) certificate.

Obtaining a Self-signed Certificate

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 self-signed certificate with OpenSSL:

openssl req -new -x509 -days 1095 -keyout key.pem -out cert.pem -newkey rsa:2048 -subj "/CN=hostname.example.org"

References

[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: 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