Getting a recognised CA certificate

The UK federation now recommends use of a self-signed certificate embedded in the metadata for the federation trust fabric. This means that most federation entities do not need a CA certificate recognised by the federation any more, but there may be some circumstances in which they do, so information about federation-recognised CA certificates is provided on this page. Please read the UK federation's certificate recommendations for identity providers and service providers for more information.

The following describes how to obtain one of the X.509 SSL certificate products from a certification authority (CA) recognised by the federation; these are known as "recognised CA certificates". This means that the certificate can be used in the federation trust fabric by means of a KeyName element in the metadata containing the CN of the certificate as its value.

At present, the X.509 CA certificates recognised by the federation are:

Choosing the certificate product

  • Wildcard certificates, from any source, are not recommended for use within the federation trust fabric.
  • If your organisation is not eligible for either of the two recognised CA certificates listed above then you can use a self-signed certificate (its contents to be included in an X509Certificate element in the metadata) for the federation trust fabric, as recommended. Alternatively, at the discretion of the federation operator, you may be able to use another CA certificate, again by including its contents in an X509Certificate element in the metadata.
  • Please note that Thawte SSL web server certificates and VeriSign Secure Site certificates are no longer recognised by the federation, so we do not recommend you purchase one of those products for the federation trust fabric. However, if you already have a Thawte SSL web server certificate issued before 27th June 2010, or a VeriSign Secure Site certificate issued before 10th October 2010 then it will still be acceptable for the federation trust fabric.

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 private 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 private key file.
  • Never email it to anybody. Email is not secure.
  • Make the private key file inaccessible to other users. This is not the default on some Unix systems.

To make a file inaccessible to 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 enter 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

Certificates issued by a CA expire regularly, usually every 1-3 years, and must be renewed. We recommend that you create a new private key when you renew the certificate.

If the contents of a CA certificate are being used in the federation trust fabric and therefore have been included in the metadata registered in the UK federation for your entity, and you wish to use the renewed certificate in the trust fabric also, then you should email the UK federation service desk to request the metadata update a few days (preferably at least a week) before the old certificate expires, and attach the renewed certificate to your email. The new certificate should be added to your entity's metadata in addition to the old certificate, in the first instance.

The federation technical support team will advise you of the most suitable approach for coordinating the change of your configuration with the change of the metadata. Please note that you should not change your configuration before sending the new certificate to the federation service desk.