Article : OpenVPN_Key_generation

OpenVPN Quickstart

Originaly from :http://openvpn.net/index.php/open-source/documentation/howto.html#pki

While this HOWTO will guide you in setting up a scalable client/server VPN using an X509 PKI (public key infrastruction using certificates and private keys), this might be overkill if you are only looking for a simple VPN setup with a server that can handle a single client.

If you would like to get a VPN running quickly with minimal configuration, you might check out the Static Key Mini-HOWTO.

Static Key advantages

Static Key disadvantages


Installing OpenVPN

OpenVPN can be downloaded here.

For security, it's a good idea to check the file release signature after downloading.

The OpenVPN executable should be installed on both server and client machines, since the single executable provides both client and server functions.

Linux Notes (using RPM package)

If you are using a Linux distribution which supports RPM packages (SuSE, Fedora, Redhat, etc.), it's best to install using this mechanism. The easiest method is to find an existing binary RPM file for your distribution. You can also build your own binary RPM file:

rpmbuild -tb openvpn-[version].tar.gz

Once you have the .rpm file, you can install it with the usual

rpm -ivh openvpn-[details].rpm

or upgrade an existing installation with

rpm -Uvh openvpn-[details].rpm

Installing OpenVPN from a binary RPM package has these dependencies:

Furthermore, if you are building your own binary RPM package, there are several additional dependencies:

See the openvpn.spec file for additional notes on building an RPM package for Red Hat Linux 9 or building with reduced dependencies.

Linux Notes (without RPM)

If you are using Debian, Gentoo, or a non-RPM-based Linux distribution, use your distro-specific packaging mechanism such as apt-get on Debian or emerge on Gentoo.

It is also possible to install OpenVPN on Linux using the universal ./configure method. First expand the .tar.gz file:

tar xfz openvpn-[version].tar.gz

Then cd to the top-level directory and type:

./configure
make
make install

Windows Notes

OpenVPN for Windows can be installed from the self-installing exe file on the OpenVPN download page. Remember that OpenVPN will only run on Windows 2000 or later. Also note that OpenVPN must be installed and run by a user who has administrative privileges (this restriction is imposed by Windows, not OpenVPN). The restriction can be sidestepped by running OpenVPN in the background as a service, in which case even non-admin users will be able to access the VPN, once it is installed. More discussion on OpenVPN + Windows privilege issues.

OpenVPN can also be installed as a GUI on Windows, using Mathias Sundman's installation package, which will install both OpenVPN and the Windows GUI.

After you run the Windows installer, OpenVPN is ready to use and will associate itself with files having the .ovpn extension. To run OpenVPN, you can:

A GUI is also available for the Windows version of OpenVPN.

Additional Windows install notes.

Mac OS X Notes

Angelo Laub and Dirk Theisen have developed an OpenVPN GUI for OS X.

Other OSes

Some notes are available in the INSTALL file for specific OSes. In general, the

./configure
make
make install

method can be used, or you can search for an OpenVPN port or package which is specific to your OS/distribution.


Determining whether to use a routed or bridged VPN

See FAQ for an overview of Routing vs. Ethernet Bridging. See also the OpenVPN Ethernet Bridging page for more notes and details on bridging.

Overall, routing is probably a better choice for most people, as it is more efficient and easier to set up (as far as the OpenVPN configuration itself) than bridging. Routing also provides a greater ability to selectively control access rights on a client-specific basis.

I would recommend using routing unless you need a specific feature which requires bridging, such as:


Numbering private subnets

Setting up a VPN often entails linking together private subnets from different locations.

The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets (codified in RFC 1918):

10.0.0.0

10.255.255.255

(10/8 prefix)

172.16.0.0

172.31.255.255

(172.16/12 prefix)

192.168.0.0

192.168.255.255

(192.168/16 prefix)

While addresses from these netblocks should normally be used in VPN configurations, it's important to select addresses that minimize the probability of IP address or subnet conflicts. The types of conflicts that need to be avoided are:

For example, suppose you use the popular 192.168.0.0/24 subnet as your private LAN subnet. Now you are trying to connect to the VPN from an internet cafe which is using the same subnet for its WiFi LAN. You will have a routing conflict because your machine won't know if 192.168.0.1 refers to the local WiFi gateway or to the same address on the VPN.

As another example, suppose you want to link together multiple sites by VPN, but each site is using 192.168.0.0/24 as its LAN subnet. This won't work without adding a complexifying layer of NAT translation, because the VPN won't know how to route packets between multiple sites if those sites don't use a subnet which uniquely identifies them.

The best solution is to avoid using 10.0.0.0/24 or 192.168.0.0/24 as private LAN network addresses. Instead, use something that has a lower probability of being used in a WiFi cafe, airport, or hotel where you might expect to connect from remotely. The best candidates are subnets in the middle of the vast 10.0.0.0/8 netblock (for example 10.66.77.0/24).

And to avoid cross-site IP numbering conflicts, always use unique numbering for your LAN subnets.


Setting up your own Certificate Authority (CA) and generating certificates and keys for an OpenVPN server and multiple clients

Overview

The first step in building an OpenVPN 2.0 configuration is to establish a PKI (public key infrastructure). The PKI consists of:

OpenVPN supports bidirectional authentication based on certificates, meaning that the client must authenticate the server certificate and the server must authenticate the client certificate before mutual trust is established.

Both server and client will authenticate the other by first verifying that the presented certificate was signed by the master certificate authority (CA), and then by testing information in the now-authenticated certificate header, such as the certificate common name or certificate type (client or server).

This security model has a number of desirable features from the VPN perspective:

Generate the master Certificate Authority (CA) certificate & key

In this section we will generate a master CA certificate/key, a server certificate/key, and certificates/keys for 3 separate clients.

For PKI management, we will use a set of scripts bundled with OpenVPN.

If you are using Linux, BSD, or a unix-like OS, open a shell and cd to the easy-rsa subdirectory of the OpenVPN distribution. If you installed OpenVPN from an RPM file, the easy-rsa directory can usually be found in /usr/share/doc/packages/openvpn or /usr/share/doc/openvpn-2.0 (it's best to copy this directory to another location such as /etc/openvpn, before any edits, so that future OpenVPN package upgrades won't overwrite your modifications). If you installed from a .tar.gz file, the easy-rsa directory will be in the top level directory of the expanded source tree.

If you are using Windows, open up a Command Prompt window and cd to \Program Files\OpenVPN\easy-rsa. Run the following batch file to copy configuration files into place (this will overwrite any preexisting vars.bat and openssl.cnf files):

init-config

Now edit the vars file (called vars.bat on Windows) and set the KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL parameters. Don't leave any of these parameters blank.

Next, initialize the PKI. On Linux/BSD/Unix:

. ./vars
./clean-all
./build-ca

On Windows:

vars
clean-all
build-ca

The final command (build-ca) will build the certificate authority (CA) certificate and key by invoking the interactive openssl command:

ai:easy-rsa # ./build-ca
Generating a 1024 bit RSA private key
............++++++
...........++++++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [KG]:
State or Province Name (full name) [NA]:
Locality Name (eg, city) [BISHKEK]:
Organization Name (eg, company) [OpenVPN-TEST]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:OpenVPN-CA
Email Address [me@myhost.mydomain]:

Note that in the above sequence, most queried parameters were defaulted to the values set in the vars or vars.bat files. The only parameter which must be explicitly entered is the Common Name. In the example above, I used "OpenVPN-CA".

Generate certificate & key for server

Next, we will generate a certificate and private key for the server. On Linux/BSD/Unix:

./build-key-server server

On Windows:

build-key-server server

As in the previous step, most parameters can be defaulted. When the Common Name is queried, enter "server". Two other queries require positive responses, "Sign the certificate? [y/n]" and "1 out of 1 certificate requests certified, commit? [y/n]".

Generate certificates & keys for 3 clients

Generating client certificates is very similar to the previous step. On Linux/BSD/Unix:

./build-key client1
./build-key client2
./build-key client3

On Windows:

build-key client1
build-key client2
build-key client3

If you would like to password-protect your client keys, substitute the build-key-pass script.

Remember that for each client, make sure to type the appropriate Common Name when prompted, i.e. "client1", "client2", or "client3". Always use a unique common name for each client.

Generate Diffie Hellman parameters

Diffie Hellman parameters must be generated for the OpenVPN server. On Linux/BSD/Unix:

./build-dh

On Windows:

build-dh

Output:

ai:easy-rsa # ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
.................+...........................................
...................+.............+.................+.........
......................................

Key Files

Now we will find our newly-generated keys and certificates in the keys subdirectory. Here is an explanation of the relevant files:

Filename

Needed By

Purpose

Secret

ca.crt

server + all clients

Root CA certificate

NO

ca.key

key signing machine only

Root CA key

YES

dh{n}.pem

server only

Diffie Hellman parameters

NO

server.crt

server only

Server Certificate

NO

server.key

server only

Server Key

YES

client1.crt

client1 only

Client1 Certificate

NO

client1.key

client1 only

Client1 Key

YES

client2.crt

client2 only

Client2 Certificate

NO

client2.key

client2 only

Client2 Key

YES

client3.crt

client3 only

Client3 Certificate

NO

client3.key

client3 only

Client3 Key

YES

The final step in the key generation process is to copy all files to the machines which need them, taking care to copy secret files over a secure channel.

Now wait, you may say. Shouldn't it be possible to set up the PKI without a pre-existing secure channel?

 

The answer is ostensibly yes. In the example above, for the sake of brevity, we generated all private keys in the same place. With a bit more effort, we could have done this differently. For example, instead of generating the client certificate and keys on the server, we could have had the client generate its own private key locally, and then submit a Certificate Signing Request (CSR) to the key-signing machine. In turn, the key-signing machine could have processed the CSR and returned a signed certificate to the client. This could have been done without ever requiring that a secret .key file leave the hard drive of the machine on which it was generated.