Getting a Certificate for an Identity Provider

(Separate information is provided for getting certificates for a Shibboleth 2.x IdP and getting certificates for an OpenAthens LA IdP.)

To set up an IdP entity within the UK federation, you normally require two X.509 digital certificates:

  • a browser-facing certificate that users will see, and
  • a trust-fabric certificate for machine-to-machine use.

These two certificates are used for different purposes and have different properties. A key length of 2048 bits is recommended for all certificates.

Browser-facing certificate

An X.509 SSL certificate is required for the browser-facing certificate, ie. the SSL certificate configured on the port 443 virtual host. Here are instructions for acquiring an SSL certificate suitable for the browser-facing certificate.

Trust fabric certificate

The federation now recommends that you use a long-life self-signed certificate for an IdP trust fabric certificate. A self-signed certificate can not be used as a browser-facing certificate.

The CN of the trust fabric certificate must match the hostname of the AttributeService and ArtifactResolutionService or equivalent URLs (usually the hostname of the identity provider server).

A key length of at least 2048 bits is mandatory for trust fabric certificates. We recommend 2048 bits, as longer keys provide no additional practical security but are more computationally expensive for all parties.

Self-signed certificate

A self-signed certificate and private key pair suitable for the federation trust fabric are generated by the Shibboleth IdP's installation script. They are stored in the credentials subdirectory of the IdP's installation directory and are called idp.crt and idp.key respectively. The Shibboleth IdP installation script also creates a Java keystore file called idp.jks containing the self-signed certificate and private key.

In the event that you no longer have the private key and certificate pair that were created when the IdP was installed, here are instructions for creating a self-signed certificate and key pair using OpenSSL.

Replacing an IdP trust-fabric certificate

A trust fabric certificate should be replaced before it expires. When replacing an embedded IdP trust fabric certificate we recommend that you follow the steps described below. Please note that this process may take between several days and several weeks so that updated metadata can propagate to federation SPs, so plenty of time should be allocated. If you aren't familiar with the process then allow at least a month.

  1. ask the UK federation support team to add the new certificate to the registered IdP metadata in the federation in addition to the old one
  2. wait for a few days, to allow the metadata to propagate to federation SPs
  3. update your IdP configuration to use the new certificate - please consult your software documentation or software vendor for details
  4. test using the UK federation test SP and check in your IdP log that the IdP used the new certificate. If you can't tell then please ask the UK federation support team to check the test SP log for you.
  5. ask the UK federation support team to remove the old certificate from the metadata

Please note: There should be no loss of service with most federation SPs if the above procedure is followed, but there are some SPs that are unable to handle the presence of more than one certificate in an IdP's metadata. We recommend you aim to keep the time at which two certificates are together in the metadata short to reduce service disruption with any such SPs.