As the story goes, Aladdin was good-for-nothing, idle, and mischievous and had no respect for his parents. Would you put your enterprise security into the hands of a rascal like that? Fortunately, with the help of some magic, the magician and the genie in the lamp finally made a sultan out of the boy .
OpenVPN and Aladdin
Luckily, you don't need magic to use Aladdin e-tokens with Linux and OpenVPN. The free SSL virtual private network (VPN) joined the mainstream with release 2.1, and it is useful for large-scale setups. Aladdin  dominates the market for USB stick-based cryptographic access control with its e-tokens – one reason they were acquired by SafeNet. However, e-token is e-token, whether labeled Aladdin or SafeNet. At a price of around US$ 100, an e-token is basically a USB device containing a user certificate. However, integrating USB stick-based authentication with password management and PIN input is not a trivial task.
In this article, we show how an organization can configure and secure a large-scale infrastructure and discuss the integration of Linux and Windows clients. We also look at customized client configurations for the VPN and a matching start script to handle PIN entry on Linux.
Tokens and Certificates
Of course, the VPN dial-up no longer uses a simple pre-shared key (PSK) but, instead, uses secure, centrally manageable X.509 certificates  that automatically expire. You can also use OpenVPN in combination with simpler, public key certificates, a technique that Strato employs for its HiDrive network storage . However, this means that you need to create the certificate as a
clientAuth certificate; otherwise, OpenVPN will not open the tunnel.
Individual client certificates and keys are preferable for the enterprise, but they still need protection, which is where Aladdin comes in with its hardware and software solution. You need a password to read the e-token, and this fulfills the "something you have and something you know" requirement imposed by data protection. On top of this, the e-token is an intelligent device that blocks the token if the user types the wrong password too many times. This precaution prevents an unauthorized third party from opening a connection without a password if the token is lost or stolen. The stored certificate is read in line with the PKCS#11 standard .
Step by Step
On a Ubuntu server, you would start by installing the
openvpn package, which depends on the
openvpn-blacklist packages. The next step is to set up your own Public Key Infrastructure (PKI). OpenVPN provides a software tool for small and medium-sized setups in the form of Easy RSA, and this tool is fine for test purposes. Admins who need larger PKIs can turn to tools like OpenCA  or outsource the task to a service provider.
No matter which tool you use, after creating the certificates, you will want to move your PKI, preferably to an isolated, internal system without a network connection. If the PKI is compromised (especially the
CA.key file), your enterprise IT landscape is at risk: The PKI should never be accessible via a network.
The Easy RSA scripts provided with the package give admins a quick and uncomplicated approach to setting up the PKI; you will find the scripts in
/usr/share/doc/openvpn/examples/easy-rsa/2.0. You can start by modifying a couple of things in the
vars; this is mainly to make the procedure more convenient (see Listing 1). After modifying these lines, you don't need to enter the details manually later on; instead, you can just type Y or press Enter. The next step is to clean up a couple of commands, export the values you just edited, and create a Diffie-Hellman (DH) key, which you need to secure the key exchange:
Listing 1: vars
01 # Key length 02 export KEY_SIZE=1024 03 04 # CA validity (in days) 05 export CA_EXPIRE=3650 06 07 # Certificate validity (in days) 08 export KEY_EXPIRE=3650 09 10 # Predefined certificate values 11 export KEY_COUNTRY="DE" 12 export KEY_PROVINCE="BY" 13 export KEY_CITY="Muenchen" 14 export KEY_ORG="Linux-Magazin" 15 export KEY_EMAIL="email@example.com" 16 17 ./clean_all 18 ./vars 19 ./build-dh.sh
After a little time, and a couple of screens full of cryptic characters, you should have your DH key and can run
./build-ca to create your own CA. The script guides you through the process, offering the predefined values from your
vars files as the defaults. You just need to type in the
Organizational Unit Name and
Common Name manually.
Next, you can create a server certificate. Easy RSA includes the
build-key-server script for this; it expects the certificate name as a parameter. This means manually entering several pieces of information, one of which is the
Common Name, typically the server's FQDN. Don't forget to include a
challenge password here, as signing will occur immediately after this process. You can say Y to the other two questions:
Sign the certificate [y/n]: 1 out of 1 certificate requests certified, \ commit? [y/n]:
After completing this step, you can issue as many user certificates as you like. Again, Easy RSA gives you a script,
build-key, for this. You need to confirm the defaults and add personal details before going on to create a TLS key to provide protection against DoS attacks. The following command is useful here:
openvpn --genkey --secret tls-auth.key
It stores the key in the
What Belongs Where?
The process of putting the certificates you create in the right places can be confusing. Figure 1 shows the correct locations: You need the
client.crt files on the OpenVPN server. On the client side (a laptop in this case) you only need the
tls-auth.key files. The
client.pem file belongs on the e-token. The lower part of the figure shows the isolated PKI management machine pushing out the
client.pem file on the right.
Finally, you just need to store the new user certificates on the users' e-tokens. The following command
openssl pkcs12 -export -in John_Doe.\ crt -inkey John_Doe.key -out \ John_Doe.p12
combines the client's certificate/key pair in a PKCS#12 file, which you then copy to the e-token using the SafeNet Authentication Client (SAC)  (formerly known as Aladdin PKI Client; it was renamed in the acquisition of Aladdin by SafeNet but contains the same functions).
When you launch this software for the first time, a button in the Advanced view initializes the e-token. You need to enter a user and administrator password for unlocking the e-token. You can also define the number of invalid attempts that a user gets before the token is blocked. The "Unlocking E-Tokens" box outlines the correct approach for reanimating an e-token using the SAC tool (Figure 2).
Import and Export
The import function helps you put the certificate on the e-token. When you are prompted for a password, enter the user password that you just assigned to be taken to another authentication dialog. If you entered a Challenge Password when issuing the user certificate, you will need to enter this now; otherwise, just leave this field blank. The e-token is now ready for use.
OpenVPN: The Server
Admins in large-scale environments will typically run OpenVPN in a separate DMZ, which is probably the ideal solution because it routes access via the centralized firewall systems and is thus controllable. But, this approach means that every VPN user needs a static IP address, for which rules are defined on the firewalls. After all, you don't want to give an external company the same privileges as an internal member of staff currently working from home.
To allow this to happen, OpenVPN version 2.1 or newer offers a topology subnet mode. In combination with the practical
ccd-exclusive parameter, it assigns a fixed IP address to the certificate/user pair and locks out unconfigured users. The administrator needs to create a configuration file with a
.conf suffix below
/etc/openvpn/ on the server (Listing 2). This file tells OpenVPN to run on TCP port 443, use a TUN device for tunneling, and use
subnet as the topology. In this mode, the OpenVPN server is assigned the first address in the designated address range (IP 192.168.1.1, in the example). The certificate and key path details are followed by the
server directive with the IP range of the virtual network.
Listing 2: /etc/openvpn/server.conf
01 port 443 02 dev tun 03 proto tcp 04 topology subnet 05 06 dh /etc/openvpn/keys/dh1024.pem 07 ca /etc/openvpn/keys/CA.crt 08 cert /etc/openvpn/keys/server.crt 09 key /etc/openvpn/keys/server.key 10 tls-auth /etc/openvpn/keys/tls-auth.key 11 12 server 192.168.1.0 255.255.255.0 13 14 keepalive 10 60 15 comp-lzo 16 17 persist-key 18 persist-tun 19 client-config-dir /etc/openvpn/ccd 20 ccd-exclusive 21 status /var/log/openvpn/status.log 22 log-append /var/log/openvpn/openvpn.log 23 verb 5
The important thing here is to modify routing on the firewall systems involved and to route the private network via the OpenVPN server. The
keepalive parameters at line 14 then tell OpenVPN to automatically terminate the tunnel after 60 seconds if the connection fails, thus allowing the user to redial.
comp-lzo directive enables compression, which noticeably increases the response that users experience when working via the tunnel.
persist-tun prevent OpenVPN reparsing the tunnel and key files when the tunnel is restarted. This makes sense if OpenVPN drops its privileges after launching, because only root is allowed to create the TUN device and parse the key file.
client-config-dir directive defines where the user configuration (e.g., with individual IP address assignments or special routes) is stored. The next directive,
ccd-exclusive, tells OpenVPN to reject any users that don't have a configuration;
verb configure the logfiles and verbosity.
The server-side configuration for user John Doe is stored in a file called
/etc/OpenVPN/ccd/John_Doe and will look pretty much like the code in Listing 3. The important thing is for the filename to match the CN from the subject line in the client certificate; in other words, you need to make sure you plan ahead when designing your PKI. The server assigns the client an IP address of 192.168.1.3 when it dials up the connection. At the same time,
redirect-gateway tells the client to run its default gateway through the VPN tunnel. Additionally, OpenVPN uses
dhcp-option to modify the DNS, WINS, and domain settings. Unfortunately, only Windows clients will understand the
dhcp-option directive, but you can use the
/etc/openvpn/update-resolv-conf script for Linux clients. If your distribution doesn't deliver this script, you can download a modified version .
Listing 3: /etc/openvpn/ccd/John_Doe
01 # John Doe 02 ifconfig-push 192.168.1.3 255.255.255.0 03 push "topology subnet" 04 push "redirect-gateway" 05 push "dhcp-option DNS 192.168.10.1" 06 push "dhcp-option WINS 192.168.10.1" 07 push "dhcp-option DOMAIN linux-magazin.de"
Of course, you could handle all the configurations listed in the
ccd directory on the client side, but this is not a good idea for security reasons. A user could easily change the IP address assigned to them to escalate their privileges. The VPN server also needs to support packet forwarding, which is handled by the
sysctl -w net.ipv4.ip_forward=1 kernel parameter.
Integrating Windows Clients
Linux and Windows clients use a totally different OpenVPN configuration. You will find the necessary Windows software at . The Linux Magazine editorial team recommends the community software offered by OpenVPN.net. The alternative from OpenVPN.se doesn't include Microsoft-certified drivers, which can cause issues with some Windows versions. Besides the OpenVPN software, you also need the SAC e-token software, which you can retrieve after registering .
After installing the two programs, you can start with the configuration. Begin by creating a
client.ovpn file with the content shown in Listing 4 in
C:\Program files\openvpn\. Note that the double backslashes aren't a typo – they are absolutely necessary. Remember to correct the path if you run a 64-bit system. It then has to be
C:\Program files (x86)\openvpn\, again with double backslashes.
Listing 4: client.ovpn (Windows)
01 remote myopenvpn.exmaple.com 443 02 dev tun 03 proto tcp 04 client 05 tun-mtu 1500 06 ca "C:\\program files\\openvpn\\keys\\ca.crt" 07 tls-auth "C:\\program files\\openvpn\\keys\\tls-auth.crt" 08 cryptoapicert "THUMB:xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx" 09 10 cipher BF-CBC 11 comp-lzo 12 register-dns 13 explicit-exit-notify
Besides the certificates, which belong in
C:\Program files\openvpn\keys, the major part of the configuration that you need to modify here is the
cryptoapicert directory. Replace the
xx:xx... section with the certificate fingerprint. Windows operating systems use a certificate store, which houses all temporary and permanent certificates. You can use an API to parse it for e-tokens, for example in the Microsoft Management Console. Click Start | Run and type
mmc in the dialog to pop up the Microsoft Management Console; then add the certificate snap-in (Figure 3).
As a final step, choose whether the MMC should open the certificate store for the current user, the service account, or the computer account. If more than one user account exists on the machine, you should use the computer account; if not, the current user's account is fine.
Next, open the crypto store and go to My Certificates to parse the plugged-in token. Double-clicking the certificate takes you to an overview of your options. Select the fingerprint, copy it, and paste it into
client.ovpn. Before quitting the MMC, add the CA certificate,
ca.crt, as a trusted root certification authority in the crypto store to indicate that the e-token is trustworthy. Although this step is not mandatory, it helps in some situations.
register-dns helps enable the DHCP options. In some cases, Windows doesn't load the new DNS configuration after establishing the tunnel.
explicit-exit-notify helps reconnect clients rapidly. With this option set, the OpenVPN client tells the server explicitly when it exists so the server can close the connection gracefully. Otherwise, the client has to wait until the server-side keepalive timeout occurs.
To allow users without administrator rights to connect with OpenVPN, you have to put them in the local group of Network Configuration Operators. In Windows 7, you also have to click OpenVPN GUI Client Properties and, under the Shortcut register, click Advanced and check Run as administrator). Otherwise, the new UAC system would prevent a functional tunnel.
Now, when you launch the OpenVPN GUI and right-click the icon in the start bar to open a connection, the SAC client asks for the token password. Assuming the password is entered correctly, the tunnel is set up immediately.
On Linux clients, you need to install the
pcscd packages and the SAC tool  (which depends, among other things, on
libhal0). Newer distributions provide
pcscd in version 1.7.0, which no longer runs as a daemon. But SAC needs a daemon. You can easily correct this by commenting out the
exit 0 line in the
/etc/init.d/pcscd startup script.
/etc/openvpn/, you can create a
client.conf file similar to the one shown in Listing 5. The certificates need to be in
/etc/openvpn/keys. Because Linux clients can't interpret the server-side
dhcp-option, you need to run
update-resolv-conf, which comes courtesy of OpenVPN or by download . The script converts the option into Linux-compliant commands, which are then run when setting up and breaking down the tunnel.
Listing 5: client.conf (Linux)
01 remote myopenvpn.exmaple.com 443 02 dev tun 03 proto tcp 04 client 05 tun-mtu 1500 06 ca /etc/openvpn/keys/ca.crt 07 tls-auth /etc/openvpn/keys/tls-auth.key 08 09 up /etc/openvpn/update-resolv-conf 10 down /etc/openvpn/update-resolv-conf 11 12 pkcs11-providers /usr/lib/libeTPkcs11.so 13 pkcs11-id 'Aladdin\x20Knowledge\x20Systems\x20Ltd\xxx/eToken/0000xxxx/eToken\xxx\xxx\xxxxxx/xxxx' 14 15 management 127.0.0.1 4711 16 management-query-passwords 17 18 cipher BF-CBC 19 comp-lzo 20 explicit-exit-notify 21 verb 3
pkcs-11-providers directive defines the path to the SafeNet library for parsing the e-token;
pkcs11-id specifies the e-token used on this system (similar to the fingerprint in the Windows configuration). To discover the string you need for this, plug in the USB stick and run
openvpn --show-pkcs11-ids \ /usr/lib/libeTPkcs11.so
(Listing 6). The fingerprint is listed in the
Serialized id field (on 64-bit systems, you have to adjust the path to
Listing 6: openvpn --show-pkcs11-ids …
01 The following objects are available for use. 02 Each object shown below may be used as parameter to 03 --pkcs11-id option please remember to use single quote mark. 04 05 Certificate 06 DN: /C=DE/ST=BY/L=Muenchen/O=Linux Magazin/OU=TR/CN=John_Doe/emailAddressfirstname.lastname@example.org 07 Serial: 03 08 Serialized id: SafeNet\x20Inc\x2E/eToken/xxxxxxxx/eToken/xxxxxxxxxxxxxxxxxx
OpenVPN Management Interface
Because Linux systems don't have a crypto store, you need to find a different approach to enabling the e-token password check. The
management-query-password lines help you do this.
If you now launch OpenVPN at the console as the root user and type
openvpn --config /etc/openvpn/client.conf, the output shows you the steps that have been processed thus far. The program normally stops after issuing the following message:
openvpn --config /etc/openvpn/client.conf [...] Sun Aug 15 15:07:56 2010 Need password(s)\ from management interface, waiting...
OpenVPN is waiting for a Telnet connection to port 4711 on the local host, where the OpenVPN management interface welcomes users with the following message:
telnet 127.0.0.1 4711 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. >INFO:OpenVPN Management Interface Version \ 1 -- type 'help' for more info >
The OpenVPN management interface requires a specific syntax for the password. Typing the following command in the Telnet session does the trick:
password 'eToken John_Doe' secret
secret is the e-token password. If you get this right, OpenVPN will set up the tunnel.
Manual Dial-Up Script
Of course you can't expect your users to do all this. Instead, the Linux Magazine editorial team has written a Bash script called Etovpn. The script is now available as test version 0.42, including packages for Debian or SUSE, or as a tarball. The script can also be downloaded .
The script opens the VPN tunnel in the background and prompts the user for their password. It then passes the password to OpenVPN via a (local) Telnet session. You can configure this in the
The client configuration directory also gives you a simple time control option. After enabling the
ccd-exclusive directive, you can easily manage a user's login time via a
mv command, which pushes the configuration file out of the
A cronjob can help automate this process and then – presto – external staff or service providers now have defined login time slots. A word of caution: This restriction doesn't apply to existing tunnels; you would need to take an existing tunnel down via the management interface on the server.