Page History

...

As of January 2010, InCommon does not issue certificates signed by the InCommon CA. We will transition the entire federation to self-signed certificates over the next two years.

Requirements

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

1. RSA keys with a minimum size of 2048 2048 bits must be used for all new submissions. We still allow current InCommon certificates that carry 1024-bit keys. However, all certificates introduced into Federation metadata.
2. No certificates with keys less than 2048 bits will be allowed in Federation metadata after December 2012.
   • All participants must migrate old 1024-bit keys out of
   the
   • metadata and upgrade to 2048-bit keys by December 2012.
3. We recommend that participants submit a new certificate with a minimum key size of 2048 bits created with a new key every 3 years. Panel No certificates with keys less than 2048 bits will be allowed in federation metadata after December 2012new 2048-bit key every 3 years.
4. Expired certificates will not be accepted for addition to one's metadata. However, current certificates that do expire may be retained in the metadata at the discretion of the participant. Shibboleth
5. InCommon does not check expiration dates of certificates, but this practice often causes interoperability issues with other software, and with some older (generally now unsupported) versions of Apache used in the deployment of the Shibboleth IdP. We recommend that participants submit a certificate with a newly-generated key every 3 years.Because the fields in the certificate are not relevant to any runtime processing or security in the federated context, InCommon will not verify or impose any requirements on certificate fields, with one caveat. At its own choosingvalidate 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 misrepresentative misrepresentated Subject information as decided by InCommon on a case by case basis. Generally, your subject information should express somewhat reasonably to you and others a a somewhat reasonable relationship between the certificate and your organization. This is up to you. Again, InCommon does not validate Subject information in self-signed certificates because this information is irrelevant to the federated security context. See also "Points to Consider" below.

Points to Consider for Interoperability

...

• 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.
• Shibboleth does not check expiration dates of certificates, but this practice often causes interoperability issues with other software, and with some older (generally now unsupported) versions of Apache used in the deployment of the Shibboleth IdP.
• 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.

...