Self-Signed Trust-Fabric Certificate
We recommended that all entities in the UK federation utilise a self-signed trust fabric certificate, 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. A lifetime of at least ten years is recommended for a self-signed trust fabric certificate.
The certificate needs to be sent to the UK federation support team with a formal request for it to be included in your entity metadata registered with the federation, and to minimise service disruption it's advisable to follow a careful key roll-over procedure. Therefore we recommend a much longer lifetime than most CAs allow, to reduce frequency of certificate replacement.
Shibboleth 2 SP
Please see the UK federation documentation on Shibboleth 2 SP certificates, which explains how to find the existing certificate files created at installation time, and how to create a new self-signed certificate and key pair.
Shibboleth 2 IdP
Please see the UK federation documentation on Shibboleth 2 IdP certificates, which explains how to find the existing certificate files created at installation time, and how to create a new self-signed certificate and key pair.
Other software - using OpenSSL
If you need to replace your existing certificate with a new self-signed certificate and key pair, and your software does not include something like keygen
), then you can use the OpenSSL software, as described below.
A suitable private key and certificate can be created in a single step using OpenSSL. On Red Hat and some other Linux distributions, OpenSSL is part of the standard distribution. For other operating systems, Windows binaries of OpenSSL and source packages for Unix systems are available via http://www.openssl.org. OpenSSL also comes bundled with some Windows binary versions of Apache httpd.
Bear in mind that you may need to seed OpenSSL's random number generator properly after installation; see the OpenSSL documentation for "openssl genrsa -rand".
The following OpenSSL command generates a private key file private.ss.key
and a self-signed certificate file certificate.ss.crt
where the key length is 2048 bits and the lifetime of the certificate is 10 years. If on a Unix/Linux system, the preceding umask command can be used to make the file inaccessible to other users:
umask 0077 openssl req -x509 -newkey rsa:2048 -keyout private.ss.key -nodes -sha256 -days 3650 -out certificate.ss.crt -extensions usr_cert
The -extensions part may be omitted if usr_cert or equivalent is not available in your system's openssl.cnf configuration, causing an error. It gives the generated certificate the form appropriate for an end-user certificate rather than a CA certificate, but this is not essential.
You will be prompted by the command to enter the Distinguished Name details for the certificate: country, organisation name and so on. The only one of these that is important for the trust-fabric certificate is the CN (Common Name), which for an identity provider must match the fully qualified domain name of the Attribute Authority (AA)'s URL (e.g., shibbox.uni.ac.uk
). Even that is not required for a service provider, although making the CN match the DNS name of the server is conventional. It should be lower case, in line with standard practice for domain names.
Make sure that the generated private key is not readable by anyone else. If on a Unix/Linux system you could have used the above umask command before creating the private key, but if for some reason the private key file is still accessible by other users you can make it inaccessible (except system administrators):
chmod go= private.ss.key
The private key and certificate files should be kept safe. If you lose either, you will need to register a new certificate with the federation. At a minimum:
- Ensure that there is a backup of the files and that the backup key is not readable by other users.