Chapter 5

The distinction between a host certificate and a user certificate is not as clear as it might seem. That is because normally IPsec requires administrative privileges, and therefore vendors tend to treat these user certificates as host certificates.

Passphrases, PIN Codes, and Interactivity

Often you want IPsec tunnels to establish without having to manually authenticate by PIN code or passphrase. It is possible to store such information in /etc/ipsec.secrets, but there is obviously some security impact. If a PIN or passphrase is necessary for Openswan to access certain data, it will try to prompt you for it. If there is no active login session (pty) this will automatically fail as if the wrong code was entered.

IKE and Certificates

When a connection is configured to use X.509 Certificates, instead of loading the RSA private key from /etc/ipsec.secrets, the private key is loaded from the certificate key file (.key), and the public key is loaded from the certificate file (.pem). These files are automatically loaded if they appear in the proper directories. Public certificates are read from the directory /etc/ipsec.d/certs, while private keys are read from the directory /etc/ipsec.d/private/. Private keys only load if they are not protected by a passphrase, or if the passphrase appears in

/etc/ipsec.secrets.

They can also be specified with a relative or absolute path.

Using the Certificate DN as ID for Openswan

We will use the DN to match our ID in the rightid= or leftid= of an IPsec connection definition. Though this seems harder than making up strings such as '@PaulsLaptop', its advantage is that it allows wildcards to group a lot of people into a single connection. The following example should make this clear:

conn x509 left=%defaultroute leftcert=vpnserver.pem

leftid="C=Ca, ST=Ontario, L=Toronto, O=Xelerance, CN=VPN Server, E=support@xelerance.com"

rightid="C=Ca, ST=Ontario, L=Toronto, O=Xelerance, CN=* E=*" right=%any

113