Getting the Browser-Facing Certificate

Overall, the procedure for obtaining the browser-facing certificate is:

  • choose a CA
  • create a private key
  • submit a Certificate Signing Request (CSR) to the CA
  • CA creates signed certificate and sends it back

Choosing the CA

The following issues should be considered when deciding which CA to use:

  • 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.
  • In general, any commercial CA can be used, provided the CA's root certificate is built in to common browsers (this is true for all the well-known CAs: VeriSign, Thawte, etc.)
  • .ac.uk organisations can obtain discounted certificates from GlobalSign.
  • In some cases a local campus CA can be used, but only if you are certain that all the users of your identity or service provider will have their browsers configured to trust this campus CA; otherwise users will receive confusing pop-up error messages. Commercial certificates avoid this issue because they are trusted by most browsers.

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

The contents of the key file must be kept secret. Otherwise, supposedly secure communications can be intercepted or faked. At a minimum:

  • Only those responsible for maintainence of the Shibboleth server should be allowed access to the key file.
  • Never email it to anybody. Email is not secure.
  • Make the key file inaccessible to other users. This is not the default on some 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 the web server will need to read the key, the password must usually be put into its 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. At a minimum:

  • Ensure there is a backup of the key file and that it is equally secret.

Generating the Certificate Signing Request

Using the key you made above, you must now create a Certificate Signing Request (CSR) file containing your public key, the DNS name to be certified and the name of your organisation. A CSR file can be generated by openssl: 

 openssl req -new -key my.key -out my.csr

When you run this command, openssl should prompt you to input Country Name (GB), your Organisation Name, Organisational Unit and Common Name.

  • The Common Name given must be the fully qualified domain name part of the URLs that you intend to use the certificate for. In simple cases this will just be the DNS name of the server, e.g., shibbox.uni.ac.uk.
  • The Organisation Name must exactly match the full formal name of your organisation as known to the CA. For SCS certificates, your local contact who deals with SCS certificate requests (the proxy) should be able to tell you the exact string to use: JANET(UK) will check this against public lists of educational organisations. For other CAs, the name must match the supporting paperwork which the CA will request from you.
  • The Organisational Unit given should reflect any existing practice within your organisation (faculty, department, etc.) For SCS certificates, guidelines may be available from your local proxy.
  • Finally, openssl may also ask for a "challenge password" and optional company name, both of which are usually left empty (the default).

Make sure all of the information entered into the Certificate Signing Request is exactly what you want: it can't be changed after the certificate is issued.

Submitting the Certificate Signing Request

Once you have made the CSR file, you need to send it to the Certification Authority. You must also prove to the CA that you are a legitimate user of the requested Organisation and DNS names. The procedure for submitting the CSR will be described in the CA's published documentation. For the particular case of JANET Certificate Service certificates, see:

Expect to spend a fair amount of time on the certification process (days rather than minutes or hours). The objective is not to issue the certificate in the shortest time possible but for the CA 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.

Certificate Renewal

Browser-facing certificates issued by a CA expire regularly, usually every 1-3 years, and must be renewed (browsers do not accept expired certificates). If you have followed the recommendation above and put the certificate in a single file referenced from wherever it is used in the software configuration, then when the certificate is renewed only this file needs to be updated. This is a purely local reconfiguration: the federation is not involved at all (even if you switch to a different CA).