Getting a Certificate
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 interoperability 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.
At present, the x.509 CA certificates recognised by the federation are:
- JANET Certificate Service certificates
- TERENA Server Certificate Service (TERENA SCS) certificates (for some non-UK European registrants)
- Thawte SSL web server certificates
- VeriSign Secure Site certificates
Choosing The CA
The following issues should be considered when deciding which certificate product to use:
- Wildcard certificates, from any source, are not recommended for use within the federation.
- JANET-connected organisations will normally choose to use free JANET Certificate Service certificates rather than purchase from a commercial supplier, unless the same certificate is also to be used to secure financial transactions.
- There is a modest cash charge for commercial certificates.
Using Other CAs
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:
- SSO service assertion signing certificate and attribute authority SSL server certificate (for an identity provider)
- Attribute requester client certificate (for a service provider)
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.
Making The Private Key
You will need to generate a public/private key pair manually. If you don't already have a suitable key pair, you can create one using openssl:
openssl genrsa 2048 > my.key
This generates a key length of 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 key file must be kept secret. Otherwise, supposedly secure communications can be intercepted or faked. At a minimum:
- Make the key file inaccessible to other users. This is not the default on most Unix systems.
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:
- Ensure that there is a backup of the key file and that it is equally secret.
Generating a Certificate Signing Request
Once you have a key pair, you need to send the public key 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 in particular it is important that the CN of the certificate matches the fully qualified domain name of the AA and Artifact URLs (usually the fully qualified domain name of the Shibboleth 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.