Getting a Certificate

In order to join the UK federation, you will need to obtain one of the X.509 digital certificate products recognised by the federation. At present, these are:

  • GlobalSign OrganizationSSL certificates
  • JANET Server Certificate Service (JANET SCS) certificates
  • TERENA Server Certificate Service (TERENA SCS) certificates
  • Thawte SSL web server certificates
  • UK e-Science CA host certificates
  • VeriSign Secure Site certificates

However, you should also check section 5.2 of the Technical Recommendations for Participants for further details of which certificates are acceptable.

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 SCS certificates rather than purchase from a commercial supplier, unless the same certificate is also to be used to secure financial transactions.
  • If an e-Science certificate is seen by a user's browser, a dialogue stating that the certificate is not trusted will appear unless that user has manually installed into their browser the corresponding CA root certificate and any intermediate CA certificates. The other certificate types avoid this user education issue because they are already trusted by common desktop browsers.
  • 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

If you want to obtain an e-Science certificate, you should skip the rest of this page and go straight to GetUKeSciCert, which describes generating a key pair with a browser rather than with openssl.

Otherwise, you will need to generate a public/private key pair manually. If you don't already have a suitable (1024-bit) key pair, you can create one using openssl: 

 openssl genrsa 1024 > my.key

Note that a key length of 1024 is now the minimum acceptable. 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

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 you lose it, you will need to get a new certificate and reapply to join the federation. 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). 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.