Creating an Environment for Your Certification Authority

48 In this section, well go through the necessary steps to set up a CA using OpenSSLs command- line tools. Well show you how to create a self-signed root certificate for use by your CA, how to build a configuration file that OpenSSL can use for your CA, and how to issue certificates and CRLs with your CA. Since OpenSSLs command-line CA functionality was intended primarily as an example of how to use OpenSSL to build a CA, we dont recommend that you attempt to use it in a large production environment. Instead, it should be used primarily as a tool to learn how PKI works and as a starting point for building a real CA with tools designed specifically for use in a production environment.

3.3.1 Creating an Environment for Your Certification Authority

The first step in setting up a CA with the OpenSSL command-line tool is creating an environment for it to run in. Several files and directories must be created. The easiest way to set everything up is from the command line, using your favorite text editor to create the necessary files. For our example CA, well be using the bash shell on a Unix system. Whether the system is Linux or FreeBSD or some other variety of Unix doesnt matter; the instructions will be the same. There will be some variation for Windows-based systems. First, we must choose a location for all of our CAs files to reside. For our example, we use optexampleca as the root directory for our CA, but you may choose any location you like on your system. All of our CAs files, including issued certificates and CRLs, will be contained within this directory. Keeping the files together makes it easier to find any of the files used by our CA and to set up multiple CAs. Within the CAs root directory, we need to create two subdirectories. Well name them certs and private . The subdirectory certs will be used to keep copies of all of the certificates that we issue with our CA. The subdirectory private will be used to keep a copy of the CA certificates private key. For the most part, the majority of the files that the CA uses are visible to anyone on the system. In fact, many of the files are supposed to be distributed to the public, or at least to anyone who makes any use of the certificates issued by our CA. The one notable exception is the CA certificates private key. The private key should never be disclosed to anyone not authorized to issue a certificate or CRL from our CA. A good CA needs to protect its private key as best it can. 2,048 bits are the bare minimum length for a CA key. The private key should be stored in hardware, or at least on a machine that is never put on a network CSRs would arrive via the sneaker net. Besides key generation, we will create three files that our CA infrastructure will need. The first file is used to keep track of the last serial number that was used to issue a certificate. Its important that no two certificates ever be issued with the same serial number from the same CA. Well call this file serial and initialize it to contain the number 1. OpenSSL is somewhat quirky about how it handles this file. It expects the value to be in hex, and it must contain at least two digits, so we must pad the value by prepending a zero to it. The second file is a database of sorts that keeps track of the certificates that have been issued by the CA. Since no certificates have been issued at this point and OpenSSL requires that the file exist, well simply create an empty file. Well call this file index.txt see Example 3-1 . Example 3-1. Creating the CAs environment mkdir optexampleca cd optexampleca mkdir certs private chmod g-rwx,o-rwx private echo 01 serial touch index.txt 49

3.3.2 Building an OpenSSL Configuration File