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.)
  • 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 maintenance 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 this documentation about making keys.

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 (CSR)

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 CN or 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 JANET Certificate Service certificates, your local contact who deals with JANET Certificate Service 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 JANET Certificate Service 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 the JANET Certificate Service, please see the documentation about requesting a JANET Certificate Service certificate.

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). We recommend that you create a new private key when you renew the certificate. When the certificate is renewed your configuration can be updated by first taking a back-up copy of the old certificate and key files and then copying the new ones over them. This is a purely local reconfiguration: the federation is not involved at all (even if you switch to a different CA).

Please note, though, that if you are also using the browser-facing certificate as a trust fabric certificate that you should contact the UK federation and ask for the new certificate to be added to the entity's metadata before you update your configuration.