Certificate Rollover for Service Providers

Last updated: May 30, 2024
Audience: IT Staff / Technical

This document describes a process for safely changing the certificate used by a Shibboleth Service Provider. It is specifically geared towards replacing a 1024-bit certificate with a 2048-bit certificate in InCommon metadata to meet new Federation policies. All Service Providers with 1024-bit certificates must transition to 2048-bit certificates by 12/31/2012.

Procedure

There are two primary roles in this process: the Service Provider Operator (Operator) and the InCommon UW Site Administrator (Site Admin). Note that InCommon now requires a display name for each SP and no updates to metadata can be made until the display name is provided. The Operator must provide a display name before step 6 can be completed. InCommon’s guidance for display names says “The SP Display Name is a user friendly name for the service (not the organization)”.

  1. Operator creates a new certificate and private key using OpenSSL. The certificate should be self-signed, 2048-bits, and have an expiration date 10 or more years in the future.
  2. Operator copies the certificate and key into the appropriate directory on the Service Provider.
  3. Operator updates the shibboleth2.xml file to reference the new certificate.
    1. The new certificate should be the first one in the configuration.
    2. Add a usage contraint for the new certificate that says use=”encryption”.
    3. It is assumed that the old certificate has no usage constraint specified (which equals the default value of use for signing and encryption).
  4. Operator sends the new certificate to the Site Admin assigned for this process.
  5. Site Admin adds the new certificate to the SP’s InCommon metadata.
  6. Operator and Site Admin wait for propagation of the new Federation metadata throughout the Federation. Propagation will take a minimum of one InCommon business day and maximum of a really long time. It just depends on the metadata refresh configuration of all the IdPs the SP accepts logons from. Operator can check in with each of those IdPs or just wait an arbitrary period of time and assume that is good enough. One week is probably adequate.
  7. Operator updates the shibboleth2.xml configuration so that the new certificate has no usage constraint and the old certificate has use=”encryption”.
  8. Site Admin removes the reference to the old certificate in InCommon metadata.
  9. Operator and Site Admin wait for propagation of the new Federation metadata throughout the Federation again.
  10. Operator removes reference to the old certificate in shibboleth2.xml and deletes the old certficate and private key from the SP.

See Also