PKI

This is a cheat sheet for setting up a personal public key infrastructure. It uses a lightly modified version of the easyrsa script distributed with OpenVPN. The version used here requires the host machine to have OpenSSL version 1.0.x+.

Set up a CA template directory

Start by setting up a template directory to use for Certificate Authorities. This (along with everything to follow) is best done on an offline storage target such as a flash drive that is never plugged into an internet-connected machine.

1. Download the EasyRSA code.
2. Unpack it onto the target target and rename the directory to something that makes sense, like template.ca. Note that the only directory that is actually used is easyrsa3, so you may just want to grab that. It might also be a good idea to keep the READMEs.
3. Patch the files easyrsa, openssl-1.0.cnf, and vars.example. (Optional)

Set up a root CA

The root CA will be the apex of your PKI system. Its certificate will be the origin of trust of all the rest of your certificates.

1. Copy the template directory to an aptly named new directory on the storage target, for example root.ca.
2. If desired, rename the root CA's vars.example file to vars and edit it. You can also edit openssl-1.0.cnf. If you want to change the name of your CA's key, certificate, and request files from the generic ca.{key,crt,req}, you'll need to edit both.
3. Set up the CA with the following. In the build-ca step you'll be asked for a master password (make it really secure!) and the Common Name to give your CA.

> sh easyrsa init-pki
> sh easyrsa build-ca

Set up an intermediate CA

While theoretically there's nothing wrong with generating all of your certificates directly from the root CA, it may be a good idea to have separate intermediate CAs set up for different purposes. If configured properly, all trust will still flow up to the root CA.

1. Copy the template directory to an aptly named new directory on the storage target, for example intermediate.ca.
2. If desired, rename the CA's vars.example file to vars and edit it. You can also edit openssl-1.0.cnf. If you want to change the name of your CA's key, certificate, and request files from the generic ca.{key,crt,req}, you'll need to edit both. For the remainder of this example, we'll assume the filenames were changed to intermediate.{key,crt,req}.
3. Set up the CA with the following. In the build-ca step you'll be asked for a master password and the Common Name to give your intermediate CA.

> sh easyrsa init-pki
> sh easyrsa build-ca subca

4. Copy the pki/reqs/intermediate.req file into the parent CA's (usually the root CA) pki/reqs directory.
5. In the parent CA's directory, sign the request with the following. You'll be asked to confirm the details, and then to enter the parent CA's password.

> sh easyrsa sign-req ca intermediate

6. Copy the resulting pki/issued/intermediate.crt file into the intermediate CA's pki directory (not the issued directory).

Generate and configure an Apache SSL server certificate

In order to avoid certificate issues, you'll need to generate a different SSL certificate for each Apache virtual host. Best practice dictates that you should generate the private key and a certificate signing request on the apache server itself so that the private key doesn't have to be transported, but as I like to keep a backup copy of the server keys anyway, we'll generate everything from the CA. For this example, we'll generate a certificate for site.example.local.

1. In the CA's directory, issue the following:

> sh easyrsa build-server-full site.example.local nopass

2. Copy the following files to the apache server, and make sure that the user under which apache runs can read them. The following sample locations work for an Ubuntu server:

   PKI file	Apache server location (ex)
   pki/private/site.example.local.key	/etc/ssl/private/
   pki/issued/site.example.local.crt	/etc/ssl/certs/
   pki/intermediate.crt	/etc/ssl/certs/
   Root CA's pki/ca.crt	/etc/ssl/certs/

3. Set the following attributes in the Apache virtual host config:

SSLCertificateFile       /etc/ssl/certs/site.example.local.crt
SSLCertificateKeyFile    /etc/ssl/private/site.example.local.key
SSLCertificateChainFile  /etc/ssl/certs/intermediate.crt

Configure an Apache server to require client certificates

In order to set up an Apache server to use client certificate authentication, you'll first need to create a chained certificate file for intermediate CA certificate that signs the client certificates. This is just the concatenation of the intermediate certificate and the root CA certificate:

> cat intermediate.crt root.crt > intermediate.chain.crt

This assumes that you're using an intermediate CA and that it's signed directly by the root CA. If you're only using a single root CA, you can ignore the chain file and the SSLCADNRequestFile parameter below. If you have additional intermediate CAs between the CA that signed your client certificates and the root CA, add them in order in the chain file and change the below SSLVerifyDepth parameter appropriately.

Add the following parameters to the HTTPS section of the virtual host configuration:

SSLVerifyClient require
SSLVerifyDepth 2
SSLCACertificateFile /etc/ssl/certs/intermediate.chain.crt
SSLCADNRequestFile /etc/ssl/certs/intermediate.crt

Generate SSL client certificates

To use key-based client authentication, you'll want to create a signed certificate for each user. Best practice dictates that you should generate the private key and a certificate signing request on the user's device so that the private key doesn't have to be transported, but as I like to keep a backup copy of all of my keys anyway, we'll generate everything from the CA. For this example, we'll generate a certificate for client1 signed by CA intermediate.

1. In the CA's directory, issue the following:

> sh easyrsa build-client-full client1.intermediate nopass (Note: appending the CA's name to the client's name isn't necessary, but I like to do it for easy identification of the files.)

2. Copy the pki/issued/client1.intermediate.crt and pki/private/client1.intermediate.key files to a location on the client's device only readable by the user. For example, ~/.ssl
3. Browsers and other client software may require a combined certificate/key file in PKCS#12 format. You will need to copy the signing CA's certificate file (e.g. intermediate.crt) to the client's device. Then, on the client, in the location of the files, run:

> openssl pkcs12 -export -out client1.intermediate.p12 -in client1.intermediate.crt -inkey client1.intermediate.key -certfile intermediate.crt