- •Credits
- •About the Author
- •About the Reviewers
- •www.PacktPub.com
- •Table of Contents
- •Preface
- •Introduction
- •Shortest setup possible
- •OpenVPN secret keys
- •Multiple secret keys
- •Plaintext tunnel
- •Routing
- •Configuration files versus the command-line
- •Complete site-to-site setup
- •3-way routing
- •Introduction
- •Setting up the public and private keys
- •Simple configuration
- •Server-side routing
- •Routing: subnets on both sides
- •Redirecting the default gateway
- •Using an 'ifconfig-pool' block
- •Using the status file
- •Management interface
- •Proxy-arp
- •Introduction
- •Simple configuration—non-bridged
- •Enabling client-to-client traffic
- •Bridging—Linux
- •Bridging—Windows
- •Checking broadcast and non-IP traffic
- •External DHCP server
- •Using the status file
- •Management interface
- •Introduction
- •Certificate generation
- •xCA: a GUI for managing a PKI (Part 1)
- •xCA: a GUI for managing a PKI (Part 2)
- •OpenSSL tricks: x509, pkcs12, verify output
- •Revoking certificates
- •The use of CRLs
- •Checking expired/revoked certificates
- •Intermediary CAs
- •Multiple CAs: stacking, using --capath
- •Introduction
- •Initializing a hardware token
- •Getting a hardware token ID
- •Using a hardware token
- •Selecting a PKCS#11 certificate using the management interface
- •Generating a key on the hardware token
- •Private method for getting a PKCS#11 certificate
- •Pin caching example
- •Introduction
- •Using a client-side up/down script
- •Windows login greeter
- •Using client-connect/client-disconnect scripts
- •Using a 'learn-address' script
- •Using a 'tls-verify' script
- •Using an 'auth-user-pass-verify' script
- •Script order
- •Script security and logging
- •Using the 'down-root' plugin
- •Using the PAM authentication plugin
- •Introduction
- •Cipher mismatches
- •TUN versus TAP mismatches
- •Compression mismatches
- •Key mismatches
- •Troubleshooting MTU and tun-mtu issues
- •Troubleshooting network connectivity
- •How to read the OpenVPN log files
- •Introduction
- •The missing return route
- •Missing return routes when 'iroute' is used
- •Source routing
- •Routing and permissions on Windows
- •Troubleshooting client-to-client traffic routing
- •Understanding the 'MULTI: bad source' warnings
- •Failure when redirecting the default gateway
- •Introduction
- •Optimizing performance using 'ping'
- •OpenSSL cipher speed
- •Compression tests
- •Traffic shaping
- •Tuning UDP-based connections
- •Tuning TCP-based connections
- •Analyzing performance using tcpdump
- •Introduction
- •Linux: using NetworkManager
- •MacOS: using Tunnelblick
- •Windows Vista/7: elevated privileges
- •Windows: using the CryptoAPI store
- •Windows: updating the DNS cache
- •Windows: running OpenVPN as a service
- •Windows: public versus private network adapters
- •Windows: routing methods
- •Introduction
- •Including configuration files in config files
- •Details of ifconfig-pool-persist
- •Connecting using a SOCKS proxy
- •Connecting via an HTTP proxy
- •Connecting via an HTTP proxy with authentication
- •Using dyndns
- •IP-less setups (ifconfig-noexec)
- •Introduction
- •Inline certificates
- •Connection blocks
- •Port sharing with an HTTPS server
- •Routing features: redirect-private, allow-pull-fqdn
- •OCSP support
- •New for 2.2: the 'x509_user_name' parameter
- •Index
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
ca |
/etc/openvpn/cookbook/ca+subca.pem |
cert |
/etc/openvpn/cookbook/server.crt |
key |
/etc/openvpn/cookbook/server.key |
dh |
/etc/openvpn/cookbook/dh1024.pem |
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
ca |
/etc/openvpn/cookbook/ca.crt |
cert |
/etc/openvpn/cookbook/IntermediateClient.crt |
key |
/etc/openvpn/cookbook/IntermediateClient.key |
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:
$ |
openssl x509 -hash -noout -in IntermediateCA/keys/ca.crt |
|
|
1f5e4734 |
|
$ |
cp IntermediateCA/keys/ca.crt |
ca-dir/1f5e4734.0 |
$ |
cp IntermediateCA/keys/crl.pem |
ca-dir/1f5e4734.r0 |
When using many different CA certificates and corresponding CRLs, this method is far easier to manage then the "stacked" files.
125