Chapter 5

Creating X.509-based Connections

In this first example, we will use X.509 Certificates instead of raw RSA keys with leftrsasigkey= and rightrisasigkey= options. We are not using a CA yet, so we will sign the certificates with themselves, so-called self-signed certificates. In this case the trust comes from both ends having the public key of the other end preloaded. Only the real West and East have the private key corresponding to the public key obtained from the preloaded certificate.

When explicitly loading a certificate, Openswan implicitly trusts it, even if it has expired!

For each host, generate a host keyfile containing the private key, and a host certificate file containing the public key and the DN. You should end up with four files: west.key, west.cert,

east.key, and east.cert:

#openssl genrsa -out west.key 1024

#openssl req -new -key west.key -x509 -out west.cert

#openssl genrsa -out east.key 1024

#openssl req -new -key east.key -x509 -out east.cert

The second command will prompt you to fill in the RDNs to build a DN. It does not matter what you use for those DNs (such as country, name, or organization), since the DNs will be loaded from the two certificates, and will therefore always match. Each end will need its own private and public key, as well as the public key of the other end.

If you wish to use a passphrase to protect the key, you can add the option -des3 to the OpenSSL command, or at any later time run the following:

#mv west.key west.key.old

#openssl rsa -des3 -in west.key.old -out west.key

#rm west.key.old

Next, define the proper connection definition on East and West. On West, this would look like:

conn west-east left=193.110.157.81 leftcert=west.cert right=205.150.200.209 rightcert=east.cert #sendcr=always #nocrsend=yes auto=add

The file west.key is placed in /etc/ipsec.d/private/. The file east.key should not be present on West, as this is East's private key. The certificate files east.cert and west.cert should be placed in /etc/ipsec.d/certs/. The private keys will be loaded when Openswan starts, or when you run ipsec secrets. If they are passphrase protected, you will either need to type in the passphrase when you bring the connection up, or you can put the passphrase in the file

/etc/ipsec.secrets:

: RSA /etc/ipsec.d/private/west.key %prompt

or:

: RSA /etc/ipsec.d/private/west.key "YourPassphrase"

117

Chapter 5

Note that if the private key is not available on this host, either because it is the private key of the remote side, or because our local private key failed to load, you will be able to determine this by looking at the pubkey: line, which will be missing the text "has private key". The above example shows we only have our own private key of East, and not the private key of West. On West, you should see the opposite situation. A good habit is to verify the keyids on the pubkey line to ensure you have transferred the proper key to the proper host.

Do not specify any leftid= or rightid=. Openswan will take the DN from the certificates and use that as the ID for IKE. In fact, either East or West can be a roadwarrior, while the other end can specify right=%any because the rightid= comes from the DN.

Now we can finally bring our connection up (or, if we use auto=start, it will come up automatically at startup unless the passphrase-prompting mode is enabled).

# ipsec auto --up west-east

If everything goes well, the log should show something like:

119