In order to register an entity with the UK federation, you can either use a long-life self-signed certificate or obtain one of the X.509 SSL certificate products from a certification authority - CA certificates - recognised by the federation. A recognised CA certificate is currently recommended for an identity provider registration due to an inter-operability issue with some service providers in the federation. The CA certificate can also be used as the browser-facing certificate.
A key length of at least 2048 bits is recommended for all certificates.
For an identity provider registration the CN of the certificate must match the hostname of the AttributeService and ArtifactResolutionService URLs (usually the hostname of the identity provider server).
At present, the x.509 CA certificates recognised by the federation are:
The following issues should be considered when deciding which certificate product to use:
It is possible to use SSL server certificates from a CA other than one of those listed above (for example, a campus CA already trusted by end user browsers). Certificates from a CA recognised by the federation are only required for the following machine-to-machine Shibboleth purposes:
These certificates can be different from your other SSL server certificates, which are seen by end users, at the price of some additional configuration complexity. However, to keep things simple the rest of the documentation here assumes that a single certificate from a recognised CA is used for all purposes.
You will need to generate a private key manually. If you don't already have a suitable key, you can create one using openssl:
openssl genrsa 2048 > my.key
This generates a key with length 2048 bits, which is recommended. If openssl is not already installed, you can get it from http://www.openssl.org. Bear in mind that you may need to seed openssl's random number generator properly to avoid an attacker potentially being able to work out key values; see the documentation for openssl genrsa -rand.
The contents of the private key file must be kept secret. Otherwise, supposedly secure communications can be intercepted or faked. At a minimum:
To make a file inaccessible by other users (except system administrators):
chmod go= my.key
On Windows systems you should ensure that only those accounts which need to can access the file. This usually means ensuring that there are no permission-granting ACLs on the file, except those which grant access to the "Administrators" group. For details, see
It is also possible to encrypt the key with a password. However, because programs like Shibboleth and Apache will need to read the key, the password must usually be put in their configuration files, so this is not as helpful as it seems. It may even make things worse, if those configuration files can be read by other users. For details of this option, see MakingKeys.
The key file should also be kept safe. If your key is lost or compromised then you need to make a new key as well as getting a new certificate for that new key. At a minimum:
Once you have a private key, you need to use it to create a certificate signing request (CSR) and send it to the Certification Authority, along with the information to be certified (the DNS name of the server machine and your organisation's name). Please note: for an identity provider registration, the CN of the certificate must match the hostname of the AttributeService and ArtifactResolutionService URLs (usually the hostname of the identity provider server). You must also prove to the CA that you are a legitimate user of those names. Follow the procedure for your chosen CA from the list below:
In each case, expect to spend a fair amount of time on this process (days rather than minutes or hours). The objective is not to issue the certificate in the shortest time possible but to make extensive manual checks to ensure that the information in the certificate is genuine and correct, and prevent the issue of a certificate in your organisation's name to a fraudster wanting to pass themselves off as that organisation to unsuspecting users on the web.