5. Managing X.509 Certificates

The standard describing digital certificate formats, and the manipulations to be performed on them, is called X.509; it is somewhat complex, but OpenSSL will take care of the details for us.

5.1. Generating Your Own CA

Before generating any keys, we will have to create directories to store the generated key data and edit the OpenSSL config file openssl.cnf. The config file may be located in one of several places across your system; use locate or slocate to find it before proceeding.

The following things MUST be done:

  1. Make a directory to serve as your key working area (e.g., /etc/ssl/myCA).

  2. Create the following directories under your working area: certs, crl, newcerts, and private. Also, create an empty file called index.txt, and a file called serial containing ONLY the text 01.

  3. Change the [ CA_default ] section of your openssl.cnf as follows:

    ...
    	    
    [ CA_default ]
    	    
    dir             = /path/to/working/area
    ...
    certificate     = $dir/<cert-file>
    ...
    private_key     = $dir/private/<key-file>
    ...

    Remember the names you fill in for <cert-file> and <key-file>; you will use them later when we actually generate the certificate and key.

In addition, the following optional measures are worth pondering:

  • Consider increasing default_days under [ CA_default ] so that your VPN certificates don't expire after a year, leaving you wondering why your VPN has suddenly broken down.

  • If you are paranoid about key sizes (and paranoia is a feature rather than a bug when you are dealing with security), increase default_bits under [ req ] to 2048. Being paranoid does make more sense in a business environment than in a home; at home 1024-bit keys will still be OK, for a little while.

  • Consider making your root certificate key twice as large as the keys you will generate for authenticating the VPN machines; this makes it harder for someone to forge a certificate signature. On my own system I use a 4096-bit root certificate with 2048-bit keys for the VPN machines.

At this time it is also wise to choose an ASN.1 Distinguished Name (DN) for your certificate authority, which has the following components:

  • Country Name (2-letter ISO standard, e.g.: US)

  • State/Province Name (Full name or abbreviation, e.g.: IL)

  • Locality (City name, e.g.: Podunk)

  • Organization Name (Make up something you like)

  • Organizational Unit Name [optional] (Again, make up something you like)

  • Common Name (Your name, or another name you choose)

  • Email Address [optional] (Your email address)

WRITE DOWN THE FIRST FOUR PARTS OF THE DN. OpenSSL will require that any certificates you sign with this CA have THE SAME VALUES in those four parts of their DNs. Each certificate MUST also have a unique Common Name, and by extension a unique full DN.

Once you have edited openssl.cnf and chosen a DN for your certificate authority, issue the following command to create the keypair. The value for -days specified below makes it valid for ten years; adjust it if you so desire.

openssl req -nodes -newkey rsa:<keysize> -x509 \
        -keyout <key-file> -out <cert-file> \
        -days 3650

Enter the values chosen for your DN when it prompts you.

5.2. Generating Host Certificates

Now we want to create the certificates that will be used by the VPN software for peer authentication, and sign them with our new CA. We need unique certificates for:

  • The wired endpoint.

  • Each wireless endpoint. (You could use one certificate for every wireless endpoint in theory, but that defeats the purpose of using PKI to individually authenticate a machine.)

Execute the following two commands for each cert/key you want to create:

openssl req -nodes -new -keyout <host-key-file> \
        -out <cert-request-file>
openssl ca -out <host-cert-file> -in <cert-request-file>

When prompted, enter values for each certificate's DN; remember that the first four parts MUST match those on the CA certificate, and the Common Name MUST be unique.

Discard the request files. Copy the newly-generated cert/key pairs, as well as a copy of the CA certificate (the public certificate, NOT the private key), to the machines they were generated for, using SCP or some other secure method. Technically, only the private keys absolutely need to remain private, but a little extra security at this stage never hurt anybody.