IPSec Certificate Basicsby Mike DeGraw-Bertsch
So you've got IPSec running between your hosts using preshared keys, and you want to move to X.509 certificates? It's a good idea. They're easier to manage than shared keys, and preshared keys may disappear in IPSec version 2.
It's a relatively easy move, but if you're not familiar with OpenSSL, it can get frustrating. This article will ease that frustration by providing a step-by-step guide to deploying a certificate-based authentication scheme. The article assumes you are configuring certificates for use between various hosts and a tunnel server, but the functionality and setup are identical for transport mode as well.
Let's just run down the terms we'll be using here. X.509 certificates are based on public/private keypairs. Each certificate contains a public key, along with other information (identifying and not), such as the owner's common name and the certificate's expiration date. The owner keeps her private key in a separate file.
The certs are signed by a Certificate Authority, or CA, and contain information as to which authority signed it. This digitally proves that the certificate is authentic and that the information contained within it is accurate--perfect for verifying the identity of a remote host. The CA's authenticity is verified by its certificate, which is generally available to the public.
For more information on X.509 certificates, click here.
Running certificate-based IPSec authentication requires two
things. First off is a recent version of racoon; grab the latest
20011215a). Next is OpenSSL, version 0.9.5a or higher. The version
supplied with FreeBSD by default does not have the useful
script, so you should download and install the latest version, which
Creating your own CA
With OpenSSL, you can create your own certificates and even your own Certificate Authority--meaning that you can create, sign, and distribute certificates to the world. While the rest of the world may not recognize your standing as a CA ("Do I want to accept a certificate signed by Joe's Garage and Certificate Authority? No!"), at least you will recognize yourself as one. And that's all you need for hosts connecting to your tunnel server.
You may want to create your CA on the tunnel server, or you may not. It's up to you.
To start, login to whatever host you decide upon as your CA, and create a
directory where you'll manage your certificates. You'll then create
your CA subdirectory (
demoCA) by running:
When prompted for the CA certificate filename, press Enter. You'll then be prompted for a password to protect the CA's private key. It's very important that the password stays safe, or anyone could sign certificates as you, so make it a good one. Next, you will be prompted to enter identifying information about your location, company, common name, and email address. It's all self-explanatory, except for the common name. This is a mandatory bit of uniquely identifying data, such as your host's FQDN or your name.
After entering the required information, the
subdirectory is created. If you're paranoid, you may want to
the private key file (
demoCA/private/cakey.pem) so that
only root can read it. But this shouldn't be necessary since you
used a really good password to protect it, right?
You can ignore most of
demoCA's remaining contents,
but you'll need to use
demoCA/cacert.pem in the near
Pages: 1, 2