Automatic Key Generation
Shibboleth 2.x includes a batch/shell script that uses OpenSSL to automatically generate a keypair and self-signed certificate containing the machine's hostname. This script is run during installation on most platforms, assuming the files sp-key.pem and sp-cert.pem are not already present. To run the script by hand, simply use the keygen.bat or keygen.sh script directly. For older Shibboleth installs, you can download the script yourself from the source code repository.
Options can be supplied to the script to manually override the hostname used by the script, control the certificate lifetime, and overwrite an existing keypair. Use the -h option to see usage information.
If you are running multiple virtual hosts, you do NOT need to request multiple certificates. This certificate is not (generally) used to enable SSL on your web server and does not have to match the actual hostnames that might be visible to your users.
InCommon (federated) deployments cannot use the default certificate generated during the SP install, as the InCommon federation requires all certificates be signed by their certificate authority. Therefore, if (and only if) you are following the federated deployment steps, you should use the following command to generate a key and certificate signing request, in lieu of a self-signed certificate:
openssl req -new -newkey rsa:1024 -nodes -subj '/CN=www.myservice.arizona.edu' -keyout sp-key.pem -out sp-csr.pem
In this example, you would replace
www.myservice.arizona.edu with the hostname of your service. After running this command the private key would be found in
sp-key.pem and the CSR in
sp-csr.pem. The CSR will need to be provided during the registration process, and the signed certficate (when received) should be saved as
Private Key Protection
Your private key is like a password for your server and needs to be both available to the software while it runs but also highly secure and inaccessible. You can see that these are competing goals. People often encrypt their keys with a pass-phrase, but since the pass-phrase has to then be stored in a file, and usually that file is backed up together with the key, nothing is gained. The best solution is to set a very strict set of permissions on the key file. Only the Shibboleth service/daemon needs access to it. You may also want to back the key up to an offline device, such as a USB dongle, and place it in a lockbox. You might then exclude the private key from your backup procedures so that it does not become vulnerable to theft by anyone with access to the tapes. You MUST protect your key.
When you're done, proceed with the configuration process for an UA-specific or federated deployment, during which you will submit the certificate you generated along with additional information about your service. During the registration process, you will be contacted and asked to run another command to compute the SHA-1 hash of your certificate so that you can repeat it over the phone and verify its authenticity:
openssl x509 -fingerprint -sha1 -noout -in sp-cert.pem
Note about Multiple Servers
If the configuration of a single application or service is spread across multiple physical web servers, you can either share a single key and certificate across all of the servers, or generate a new key on each server. Each approach has its advantages and disadvantages. Using multiple keys is more technically correct and prevents a single key compromise from preventing the use of the others. However, it creates some additional work in managing independent keys and certificates. Each certificate can be logically associated by Shibboleth with your service, so the use of multiple certificates is not a technical problem for the system itself.