Openvpn verify error could not extract cn from x509 subject string

Chapter 12

The client-connect and client-disconnect scripts are very similar to the ones used in the Proxy-ARP recipe from Chapter 2, Client-server IP-only Networks. By using a handy feature of the Linux arp command, we can make the remote clients appear to be part

of the local network.

There’s more…

The topology subnet feature was introduced in OpenVPN 2.1. Without this feature, each client would be handed out a miniature /30 network, which means that each client would use up to four public IP addresses. This made the deployment of handing out public IP addresses to VPN clients very expensive.

See also

 Chapter 2‘s recipe Proxy-ARP, which explains in more detail how the Linux/UNIX Proxy-ARP feature works.

A little known fact—the client certificate’s serial number is present as an environment variable in scripts—allows OpenVPN to support the Online Certificate Status Protocol (OCSP). This recipe will show how OCSP can be set up and be supported by an OpenVPN server.

Getting ready

We use the following network layout:

New Features of OpenVPN 2.1 and 2.2

Set up the client and server certificates using the first recipe from Chapter 2, Client-server IP-only Networks. For this recipe, the machine on which the CA certificate and private key are stored is ocsp.example.com. The server computer was running CentOS 5 Linux and OpenVPN 2.1.3. The client was running Windows XP SP3 and OpenVPN 2.1.3. Keep the

configuration file basic-udp-server.conf from the Chapter 2 recipe Server-side routing at hand, as well as the client configuration file, basic-udp-client.ovpn, from the Chapter 2 recipe Using an ‘ifconfig-pool’ block.

How to do it…

1.First, start an OCSP server by re-using the PKI created in Chapter 2, Client-server IP-only Networks. On the machine ocsp.example.com run:

[ocsp]$ cd /etc/openvpn/cookbook

[ocsp]$ openssl ocsp -index keys/index.txt -port 4444

-CA keys/ca.crt -rsigner keys/ca.crt -rkey keys/ca.key -resp_text

2.Then, create the server configuration file by adding a line to the basic-udp-server.conf file:

script-security 2

tls-verify /etc/openvpn/cookbook/example12-6-ocsp.sh

Save it as example12-6-server.conf.

3.Create the tls-verify script:

#!/bin/bash

# if the depth is non-zero , continue processing [ «$1» -ne 0 ] && exit 0

cd /etc/openvpn/cookbook oscp_url=»http://ocsp.example.com:4444″ if [ -n «${tls_serial_0}» ]

then

status=$(openssl ocsp -issuer ca.crt -CAfile ca.crt -url «$ocsp_url»

-serial «0x${tls_serial_0}» 2>/dev/null)

if [ $? -eq 0 ] then

# debug:

echo «OCSP status: $status»

Chapter 12

if echo «$status» | grep -Fq «0x${tls_serial_0}: good» then

exit 0

fi else

# debug:

echo «openssl ocsp command failed!»

fi

fi exit 1

This script is based on the OCSP_verify.sh script that is found in the OpenVPN 2.2 contrib directory. Save it as example12-6-ocsp.sh.

4.Make sure the script is executable, then start the server:

[root@server]# chmod 755 example12-6-ocsp.sh [root@server]# openvpn —config example12-6-server.conf

5.Start the OpenVPN client using the basic-udp-client.ovpn configuration file.

6.Check the log file /var/log/openvpn.log on the OpenVPN server to see the following output:

OCSP status: 0x02: good

And the VPN connection will have been established successfully.

How it works…

Because the client’s certificate serial number is now present as the environment variable tls_serial_0, it becomes possible to support OCSP. By requesting verification with the OCSP server if a certificate is valid (that is, known and neither revoked nor expired) the server can verify that the client has been issued a valid certificate. This could also have been achieved using a Certificate Revocation List (CRL), but in some cases, an OCSP is more convenient to use, as CRLs need to be periodically updated.

See also

Chapter 4‘s recipe The use of CRLs, which explains Certificate Revocation

Lists (CRLs). Using CRLs is the most standard method for verifying the validity of certificates.

New Features of OpenVPN 2.1 and 2.2

New for 2.2: the ‘x509_user_name’ parameter

OpenVPN 2.2 is primarily a bug fix release, but there are a few new features added to version

2.2. In this recipe, we will focus on one of these features. The purpose of the x509_user_name parameter is to allow the usage of X509 certificates where the certificate name is not specified by the /CN= element. This can be especially useful when using certificates from a third-party source or when integrating certificates into other authorization systems.

Getting ready

We use the following network layout:

Set up the client and server certificates using the first recipe from Chapter 2, Client-server IP-only Networks. In this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.2-beta3. The client was running Windows XP SP3 and OpenVPN 2.1.3. Keep the configuration file basic-udp-server.conf from the Chapter 2 recipe Server-side routing at hand, as well as the client configuration file, basic-udp-client.ovpn, from the Chapter 2 recipe Using an ifconfig-pool block.

How to do it…

First, we generate a new certificate using low-level OpenSSL commands. This is because the OpenVPN-supplied easy-rsa scripts do not easily allow us to create a script without a /CN= part.

1.Generate a new certificate request with a special subject name:

[server]$ cd /etc/openvpn/cookbook

[server]$ openssl req -new -nodes -keyout client6.key -out client6.csr -newkey rsa:2048

-subj «/C=NL/O=Cookbook/UID=cookbook»

Chapter 12

2.Create an empty OpenSSL extensions file to ensure that the resulting certificate is an X.509 v3 certificate:

[server]$ touch openssl-ext.conf

3.And finally, sign the certificate request using the CA key:

[server]$ openssl x509 -req -CA keys/ca.crt -CAkey keys/ca.key -in client6.csr -set_serial 0xAA -sha1 -days 1000

-extfile openssl-ext.conf -out client6.crt

4.Create the server configuration file by adding the followings line to the basic-udp-server.conf file:

script-security 2

client-connect /etc/openvpn/cookbook/example12-7-client-connect.sh

x509-username-field «UID»

Save it as example12-7-server.conf.

5.Create the client-connect script:

#!/bin/bash

echo «common_name = [$common_name]»

And, save it as example12-7-client-connect.sh.

6.Make sure the script is executable, then start the server:

[root@server]# chmod 755 example12-7-client-connect.sh [root@server]# openvpn —config example12-7-server.conf

7.Copy the client6.crt and client6.key files to the Windows client using a secure channel; for example, using PuTTY’s pscp command.

8.Modify the client configuration file basic-udp-client.ovpn by changing the lines:

cert /etc/openvpn/cookbook/client2.crt key /etc/openvpn/cookbook/client2.key

to:

cert /etc/openvpn/cookbook/client6.crt key /etc/openvpn/cookbook/client6.key

Save it as example12-7.ovpn.

New Features of OpenVPN 2.1 and 2.2

9. Start the OpenVPN client:

10.Check the log file /var/log/openvpn.log on the OpenVPN server to see the following output:

common_name = [cookbook]

How it works…

With the new x509_user_name directive, OpenVPN can extract the connecting client name from a field other than the default /CN= field. In this recipe, the section /UID= was used. When a client connects with a certificate that has a subject section /UID=, the OpenVPN server extracts the client name from this field. This client name is set as the environment variable common_name for most server-side scripts and plugins, such as the client-connect, client-disconnect, and learn-address scripts, as well as the

ifconfig pool persist file.

Note that it is not possible to use just any /<field>=<name> section as part of an X509 certificate. The <field> must be all uppercase and it must be recognized by OpenSSL itself, as otherwise it is not easily possible to generate a certificate.

There’s more…

OpenVPN 2.1 behaviour

If the above certificate was used when connecting to an OpenVPN 2.1 server, the client would not have been able to connect. Instead, the following log message would appear in the server log file:

VERIFY ERROR: could not extract Common Name from X509 subject string (‘/C=NL/O=Cookbook/UID=cookbook’) — note that the Common Name length is limited to 64 characters