Apache Cookbook-Apache Cookbook

Recipe 7.2 Generating SSL Certificates

Problem

You want to generate certificates to use on your SSL server.

Solution

Use the openssl command-line program that comes with OpenSSL:

% openssl genrsa -out hostname.key 1024
% openssl req -new -key hostname.key -out hostname.csr

At this point, you can either send your Certificate Signing Request (CSR) off to one of the certificate authority companies, such as Thawte or Entrust, for them to sign, or, if you prefer, you can sign the key yourself:

% openssl x509 -req -days 365 -in hostname.csr -signkey hostname.key 
     -out hostname.crt

Then move these files to your Apache server's configuration directory, such as /www/conf/, and then add the following lines in your httpd.conf configuration file:

SSLCertificateFile /www/conf/hostname.crt
SSLCertificateKeyFile /www/conf/hostname.key

Discussion

The SSL certificate is a central part of the SSL conversation and is required before you can run a secure server. Thus, generating the certificate is a necessary first step to configuring your secure server.

Generating the key is a multistep process, but it is fairly simple.

Generating the private key

In the first step, we generate the private key. SSL is a private/public key encryption system, with the private key residing on the server and the public key going out with each connection to the server and encrypting data sent back to the server.

The first argument passed to the openssl program tells openssl that we want to generate an RSA key (genrsa), which is an encryption algorithm that all major browsers support.

The next argument gives openssl something to use as the source of randomness. The -rand flag will accept one or more filenames, which will be used as a key for the random number generator. If no -rand argument is provided, OpenSSL will attempt to use /dev/urandom by default if that exists, and it will try /dev/random if /dev/urandom does not exist. It is important to have a good source of randomness in order for the encryption to be secure. If your system has neither /dev/urandom nor /dev/random, you should consider installing a random number generator, such as egd. You can find out more information about this on the OpenSSL web site at http://www.openssl.org/docs/crypto/RAND_egd.html.

The -out argument specifies the name of the key file that we will generate. This file will be created in the directory in which you are running the command, unless you provide a full path for this argument. Naming the key file after the hostname on which it will be used will help you keep track of the file, although the name of the file is not actually important.

And, finally, an argument of 1024 is specified, which tells openssl how many bytes of randomness to use in generating the key.

Generating the certificate signing request

The next step of the process is to generate a certificate signing request. The reason it is called this is because the resultant file is usually sent to a certificate authority (CA) for signing and is, therefore, a signing request. (A certificate is just a signed key, showing that someone certifies it to be valid and owned by the right entity.)

A certificate authority is some entity that can sign SSL certificates. What this usually means is that it is one of the few dozen companies whose business it is to sign SSL certificates for use on SSL servers. When a certificate is signed by one of these certificate authorities browsers will automatically accept the certificate as being valid. If a certificate is signed by a CA that is not listed in the browser's list of trusted CAs, then the browser will generate a warning, telling you that the certificate was signed by an unknown CA and asking you if you are sure that you want to accept the certificate.

This is a bit of an oversimplification of the process but conveys enough of it for the purposes of this recipe.

The arguments to this command specify the key for which the certificate is being generated (the -key argument) and the name of the file that you wish to generate (the -out argument).

If you want a certificate that will be accepted by all major browsers, you will send the csr file, along with a check or credit card information, to one of these CAs.

Signing your key

On the other hand, you can sign your own public key (also called "signing your own certificate," since signing your public key results in a self-signed certificate), which will result in a perfectly usable certificate, and save you a little money. This is especially useful for testing purposes, but it may also be sufficient if you are running SSL on a small site or a server on your internal network.

The process of signing a key means that the signer trusts that the key does indeed belong to the person listed as the owner. If you pay Entrust or one of the other commercial CAs for a certificate, they will actually do research on you and verify, to some degree of certainty, that you really are who you claim to be. They will then sign your public key and send you the resulting certificate, putting their stamp of approval on it and verifying to the world that you are legitimate.

In the example given, we sign the key with the key itself, which is a little silly, as it basically means that we trust ourselves. However, for the purposes of the actual SSL encryption, this is sufficient.

If you prefer, you can use the CA.pl script that comes with OpenSSL to generate a CA certificate of your own. The advantage of this approach is that you can distribute this CA certificate to users, who can install it in their browsers, enabling them to automatically trust this certificate and any other certificates that you create with that same CA. This is particularly useful for large companies where you might have several SSL servers using certificates signed by the same CA.

Of the arguments listed in the command, one of the most important ones is the -days argument, which specifies how many days the certificate will be good for. If you are planning to purchase a commercial certificate, you should generate your own self-signed key that is good for perhaps 30 days, so that you can use it while you are waiting for the commercial certificate to arrive. If you are generating a key for actual use on your server, you may want to make this a year or so, so that you don't have to generate new keys very often.

The -signkey argument specifies what key will be used to sign the certificate. This can be either the private key that you generated in the first step or a CA private key generated with the CA.pl script, as mentioned above.

Configuring the server

Having generated the key and certificate, you can use them on your server using the two lines of configuration shown in the previous solution.

The easy way

Now that we've gone through the long and painful way of doing this, you should know that there is a simpler. OpenSSL comes with a handy script, called CA.pl, which simplifies the process of creating keys. The use of CA.pl is described in Recipe 7.3 so you can see it in action. It is useful, however, to know some of what is going on behind the script. At least, we tend to think so.