PKI, Certificates, and OpenSSL

Intermediary CAs

This recipe shows how to set up an intermediary CA and how to configure OpenVPN to make use of an intermediary CA. The OpenVPN easy-rsa scripts also include functionality to set up an intermediary CA. The advantage of an intermediary CA (or sub CA) is that the top-level CA (also known as the root CA) can be guarded more closely. The intermediary CAs can be distributed to the people responsible for generating the server and client certificates.

Getting ready

Set up the client and server certificates using the first recipe from Chapter 2. In this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.1. The client was running Fedora 12 Linux and OpenVPN 2.1.1.

How to do it...

1.First, we create the intermediary CA certificate: $ cd /etc/openvpn/cookbook/

$ . ./vars

$ ./build-inter IntermediateCA

2.Verify that this certificate can indeed act as a Certificate Authority:

$ openssl x509 -text -noout -in keys/IntermediateCA.crt \ | grep -C 1 CA

X509v3 Basic Constraints:

CA:TRUE

Signature Algorithm: sha1WithRSAEncryption

3.Next, we create a new keys directory for our intermediary CA (the current directory is still /etc/openvpn/cookbook):

$ mkdir -m 700 -p IntermediateCA/keys $ cp [a-z]* IntermediateCA

$ cd IntermediateCA

4.Edit the vars file and change the EASY_RSA line to:

export EASY_RSA=/etc/openvpn/cookbook/IntermediateCA

5.Source this new vars file and set up the keys directory: $ . ./vars

$ ./clean-all

120

Chapter 4

$ cp ../keys/IntermediateCA.crt keys/ca.crt $ cp ../keys/IntermediateCA.key keys/ca.key

5.Now, we are ready to create our first intermediary certificate: $ ./build-key IntermediateClient

6.Verify that the certificate has the new Intermediary CA as its issuer: $ openssl x509 -subject -issuer -noout -in \

keys/IntermediateClient.crt

subject= /C=NL/O=Cookbook/CN=IntermediateClient/… issuer= /C=NL/O=Cookbook/CN=IntermediateCA/…

7.And finally, we verify that the certificate is indeed a valid certificate. In order to do this we need to "stack" the root CA (public) certificate and the intermediary CA certificate into a single file:

$ cd /etc/openvpn/cookbook

$ cat keys/ca.crt IntermediaryCA/ca.crt > ca+subca.pem

$ openssl verify -CAfile ca+subca.pem IntermediateClient.crt

IntermediateClient.crt: OK

How it works...

The intermediary CA certificate has the "right" to act as a certificate authority, meaning that it can sign new certificates itself. The intermediary CA needs a directory structure for this, which is very similar to the root CA directory structure. First, we set up this directory structure and then we copy over all the necessary files. After that we create a client certificate and verify that it is a valid certificate. In order to perform this validation, the entire certificate chain from the root-level CA to the intermediary CA to the client certificate need to be present. This is why the root CA public certificate and the intermediary CA public certificate are stacked into a single file. This single file is then used to perform the entire certificate chain validation.

There's more...

Certificates that have been issued by an intermediary CA also need to be revoked by the same

CA. This means that with multiple CAs you will also have to use multiple CRLs. Fortunately,

CRLs can be stacked just like CA certificates: simply cat the file together, as will be explained in the next recipe.

121

PKI, Certificates, and OpenSSL

Multiple CAs: stacking, using --capath

The goal of this recipe is to create an OpenVPN setup where the client certificates are signed by a "client-only" CA and the server certificate is signed by a different "server-only" CA. This provides an extra level of operational security, where one person is allowed to create only client certificates whereas another is allowed to generate only a server certificate. This ensures that the client and server certificates can never be mixed for a Man-in-the-Middle attack.

Getting ready

Set up the server certificate using the first recipe from Chapter 2. Use the client certificate and the intermediary CA certificate from the previous recipe. For this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.1. The client was running Fedora 12 Linux and OpenVPN 2.1.1.

How to do it...

1.Create the server configuration file:

tls-server proto udp port 1194 dev tun

server 192.168.200.0 255.255.255.0

tls-auth /etc/openvpn/cookbook/ta.key 0

persist-key persist-tun keepalive 10 60

user nobody group nobody

daemon

log-append /var/log/openvpn.log

Save it as example4-9-server.conf.

122

Chapter 4

2.Start the server:

[root@server]# openvpn --config example4-9-server.conf

3.Next, create the client configuration file:

client proto udp

remote openvpnserver.example.com port 1194

dev tun nobind

tls-auth /etc/openvpn/cookbook/ta.key 1

ns-cert-type server

Save it as example4-9-client.conf. Note that we did not specify the ca+subca.pem file in the client configuration.

4.Start the client:

[root@client]# openvpn --config example4-9-client.conf

5.In the server log files, you can now see the client connecting using the certificate that was created by the Intermediary CA:

… openvpnclient:49283 [IntermediateClient] Peer Connection Initiated with openvpnclient:49283

How it works...

When the client connects to the server, the client (public) certificate is sent to the server for verification. The server needs to have access to the full certificate chain in order to do the verification, therefore, we stack the root CA certificate and the intermediary CA (or sub-CA) certificate together. This allows the client to connect to the server.

Vice versa, when the client connects, the server (public) certificate is also sent to the client. As the server certificate was originally signed by the root CA, we do not need to specify the full certificate stack here.

123

PKI, Certificates, and OpenSSL

Note that if we had forgotten to specify the ca+subca.pem file in the OpenVPN server configuration file, we would have received an error:

openvpnclient:49286 VERIFY ERROR: depth=0, error=unable to get local issuer certificate:

/C=NL/O=Cookbook/CN=IntermediateClient/…

There's more...

Apart from stacking the CA certificates, it is also possible to stack the CRLs or to use an entirely different mechanism to support multiple CA certificates and their corresponding CRLs.

Stacking CRLs

If CRLs are used in this configuration, then the CRLs from both the root CA and the intermediary CA need to be stacked:

$ cd /etc/openvpn/cookbook

$ cat keys/crl.pem IntermediateCA/keys/crl.pem > crl-stack.pem

They can then be included in the OpenVPN server configuration using:

crl-verify /etc/openvpn/cookbook/crl-stack.pem

Using the --capath directive

Another way to include multiple CAs and CRLs in the OpenVPN server configuration is to use the following directive:

capath /etc/openvpn/cookbook/ca-dir

This directory needs to contain all CA certificates and CRLs using a special naming convention:

All CA certificates must have a name equal to the 'hash' of the CA certificate, and must end with .0

All CRLs must have a name equal to the 'hash' of the CA certificate, and must end with .r0

For our root CA and intermediary CA, this would require:

$ cd /etc/openvpn/cookbook $ mkdir ca-dir

$ openssl x509 -hash -noout -in keys/ca.crt bcd54da9

124

Chapter 4

This hexadecimal number bcd54da9 is the hash of the root CA certificate:

$ cp keys/ca.crt ca-dir/bcd54da9.0 $ cp keys/crl.pem ca-dir/bcd54da9.r0

Similarly, for the intermediary CA certificiate:

When using many different CA certificates and corresponding CRLs, this method is far easier to manage then the "stacked" files.

125