- •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
The use of CRLs
This recipe shows how to configure OpenVPN to use a Certificate Revocation List (CRL). It uses the CRL created in the previous recipe. This recipe is an extension of the recipe Routing: Masquerading in Chapter 2 in the sense that the server and client configuration files are almost identical.
Getting ready
Set up the client and server certificates using the first recipe from Chapter 2, Client-server IP-only Networks. Generate the CRL using 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. Keep the server configuration file basic-udp-server.conf from the Chapter 2's recipe Server-side routing at hand.
How to do it...
1.Copy the generated CRL to a more public directory:
[root@server]# cd /etc/openvpn/cookbook [root@server]# cp keys/crl.pem .
2.Modify the server config file basic-udp-server.conf by adding the lines: crl-verify /etc/openvpn/cookbook/crl.pem
Save it as example4-6-server.conf.
3.Start the server:
[root@server]# openvpn --config example4-6-server.conf
4.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/client4.crt |
key |
/etc/openvpn/cookbook/client4.key |
tls-auth /etc/openvpn/cookbook/ta.key 1
ns-cert-type server
and save it as example4-6-client.conf.
116
Chapter 4
5.Finally, start the client:
[root@client]# openvpn --config example4-6-client.conf
The client will not be able to connect but instead the server log file shows:
This rather cryptic message proves that the client is not allowed to connect because the certificate is not valid.
How it works...
Each time a client connects to the OpenVPN server, the Certificate Revocation List (CRL) is checked to see whether the client certificate is listed. If it is, the OpenVPN server simply refuses to accept the client certificate and the connection will not be established.
There's more...
Generating a CRL is one thing and keeping it up-to-date is another. It is very important to ensure that the CRL is kept up-to-date. For this purpose, it is best to set up a cron job that updates the server CRL file overnight. There is an outstanding bug in OpenVPN related to CRL updates: each time a client connects, the OpenVPN server tries to access the CRL file. If the file is not present or not accessible, then the OpenVPN server process aborts with an error.
The proper behavior would be to temporarily refuse access to the clients but unfortunately this is not the case.
See also
The last recipe in this chapter, Multiple CAs: stacking, using –capath, in which a more advanced use of CA and CRL is explained.
117
PKI, Certificates, and OpenSSL
Checking expired/revoked certificates
The goal of this recipe is to give an insight into some of the internals of the OpenSSL CA commands. We will show how a certificate's status is changed from "Valid" to "Revoked", or "Expired".
Getting ready
Set up the client and server certificates using the first recipe from Chapter 2. This recipe was performed on a computer running CentOS 5 Linux but it can easily be run on Windows or Mac OS.
How to do it...
1.Before we can use plain openssl commands, there are a few environment variables that need to be set. These variables are not set in the vars file by default:
$ cd /etc/openvpn/cookbook $ . ./vars
$ export KEY_CN=dummy $ export KEY_OU=dummy
$ export KEY_NAME=dummy
$ export OPENSSL_CONF=/etc/openvpn/cookbook/openssl.cnf
2.Now, we can query the status of a certificate using its serial number: $ cd keys
$ openssl x509 -serial -noout -in openvpnserver.crt
serial=01
openssl ca -status 01
Using configuration from /etc/openvpn/cookbook/openssl.cnf 01=Valid (V)
This shows that our OpenVPN server certificate is still valid.
3.The certificate we revoked in the recipe Revoking certificates shows the following: $ openssl x509 -serial -noout -in client4.crt
serial=08
$ openssl ca -status 08
Using configuration from /etc/openvpn/cookbook/openssl.cnf 08=Revoked (R)
118
Chapter 4
4.If we look at the file index.txt in the /etc/openvpn/cookbook/keys directory, we see:
V 130130115906Z |
01 unknown …/CN=openvpnserver |
R 130317141936Z 100621142033Z 08 unknown …/CN=client4
5.Next, we modify this file using a normal text editor and replace the R with an E and we blank out the third field 100621142033Z with spaces. This field is the timestamp when the certificate was revoked. The second line now becomes:
E 130317141936Z |
08 unknown …/CN=client4 |
6. Now, if we check the status again we get: $ openssl ca -status 08
Using configuration from /etc/openvpn/cookbook/openssl.cnf 08=Expired (E)
If we generate the CRL again, we see that the certificate has been "un-revoked":
[server]# openssl crl -text -noout -in crl.pem | head -15 Certificate Revocation List (CRL):
Version 1 (0x0)
Signature Algorithm: md5WithRSAEncryption Issuer: /C=NL/O=Cookbook/CN=Cookbook CA/email[…] Last Update: Jun 21 15:03:10 2010 GMT
Next Update: Jul 21 15:03:10 2010 GMT Revoked Certificates:
Serial Number: 05
Revocation Date: Jun 21 14:12:17 2010 GMT Signature Algorithm: md5WithRSAEncryption
87:12:da:a1:d7:da:61:55:06:46:57:9e:e3:2c:1c:04:58:31:
b2:51:fd:0e:a0:66:43:b1:db:f4:53:b9:88:68:17:24:dd:02:
How it works...
The OpenSSL ca command generates its CRL by looking at the index.txt file. Each line that starts with an 'R' is added to the CRL, after which the CRL is cryptographically signed using the CA private key.
By changing the status of a revoked certificate to E or even V we can unrevoke a certificate.
There's more...
In this recipe, we have changed a certificate from Revoked to Expired. This would allow the client from the previous recipe to connect again to the server, as the certificate is still valid. The main reason to change a certificate from Valid to Expired in the indext.txt file
is to allow us to generate and hand out a new certificate using the exact same name.
119