Chapter 5

Since the .p12 file created by this command contains the private key, it should be protected by a passphrase. This is the export password you see in the output above. You can add -passout pass:NewPassphrase if you wish to automate this command in some script.

Certificate Revocation

When a certificate is lost or stolen, it should be revoked, so that it can no longer be used to set up an IPsec connection. Since the CA signed the now-lost certificate, we need a special exemption to deny such lost certificates even though they have been signed by our trusted CA. Revoked certificates are stored in the file crl.pem, which should be placed on the gateway in the directory

/etc/ipsec.d/crls/.

An empty CRL file should be created if no certificates have been revoked yet, using:

# openssl ca -gencrl -crldays 15 -out crl.pem -keyfile caKey.pem -cert caCert.pem

To revoke a certificate, the public certificate file is needed. You should always keep a copy of these on the signing machine. This machine should be well protected or perhaps not even be connected to the Internet at all. To revoke a certificate, use:

# openssl ca -revoke fileCert.pem -keyfile caKey.pem -cert caCert.pem

The crl.pem file will need to be updated after a new certificate has been added to the revocation list:

# openssl crl -in crl.pem -noout -text

This file should be copied onto the gateway machine, in the directory /etc/ipsec.d/crls. Openswan should then be notified to re-read the new CRL file:

# ipsec auto --rereadcrls

Mar 19 23:54:16 peace pluto[16986]: Changing to directory '/etc/ipsec.d/crls' Mar 19 23:54:16 peace pluto[16986]: loaded crl file 'crl.pem' (589 bytes)

Revoking a certificate will not cause the Openswan server to drop any connections using that certificate. That IPsec connection will stay up until the next rekey, or the next (re)connect, when the now revoked certificate will be properly rejected.

An attempt by a revoked certificate to connect will be logged, and the connection will be rejected:

Mar 19	23:58:57	peace pluto[16986]: "west-roadwarriors"[5]	193.110.157.17 #11:
Peer ID is ID_DER_ASN1_DN: 'C=CA, ST=Ontario, O=Xelerance,			OU=Support Staff,
CN=revoked.xelerance.com, E=[e-mail]'
Mar 19	23:58:57	peace pluto[16986]: "west-roadwarriors"[5]	193.110.157.17 #11:
certificate was		revoked on Mar 19 22:54:05 UTC 2005
Mar 19	23:58:57	peace pluto[16986]: "west-roadwarriors"[5]	193.110.157.17 #11:
invalid RSA public key deleted
Mar 19	23:58:57	peace pluto[16986]: "west-roadwarriors"[5]	193.110.157.17 #11:
X.509 certificate rejected
Mar 19	23:58:57	peace pluto[16986]: "west-roadwarriors"[6]	193.110.157.17 #11:
deleting connection "west-roadwarriors" instance with peer			193.110.157.17
{isakmp=#0/ipsec=#0}
Mar 19	23:58:57	peace pluto[16986]: "west-roadwarriors"[6]	193.110.157.17 #11:
no RSA	public key known for 'C=CA, ST=Ontario, O=Xelerance, OU=Support Staff,
CN=revoked.xelerance.com, E=[e-mail]'
			125

X.509 Certificates

If the certificate was in use when the certificate was revoked, you will notice that after some time the connection will fail to rekey and expire:

Mar 20 00:09:46 peace pluto[17775]: "west-roadwarriors"[2] 193.110.157.17 #1: ISAKMP SA expired (LATEST!)

Versions prior to 2.3.1 did not properly delete both Phase 1 (ISAKMP SA) and Phase 2 (IPsec SA). For version 2.3.1 and up you should also see the rejection of the IPsec SA after the ISAKMP SA expires:

Mar 20 00:44:47 peace pluto[18169]: "west-roadwarriors"[2] 193.110.157.17 #2: IPsec SA expired (LATEST!)

Dynamic CRL Fetching

When deploying X.509 on a large scale, it is not convenient to have a single crl.pem file that needs constant updating and copying to the various IPsec gateways. Openswan supports a few dynamic methods where a server is periodically queried for CRL updates. These updates can come from a crl.pem file on a web server, but can also be obtained by other methods, such as LDAP. Another method is the Online Certificate Store Protocol (OCSP).

To use dynamic CRL fetching, you must ensure Openswan is compiled with support for posix threads, cURL, and optionally LDAP. These can be enabled in Makefile.inc by setting

HAVE_THREADS, USE_LIBCURL, and USE_LDAP to true.

Your CA certificate and all signed host certificates need to be created with an additional CRL distribution section in your openssl.cnf file so that all certificates know about the type and location of the dynamic CRLs. Add the following line to the [usr_cert] section of openssl.cnf:

crlDistributionPoints= @crl_dp

And add a new [crl_dp] section listing the dynamic CRL methods and locations you wish to use:

[ crl_dp ]

URI.1="http://crl.yourorganisation.org/revoked.crl"

URI.2="ldap://ldap.yourorganisation.org/o=Xelerance,

c=CA?certificateRevocationList?base?(objectClass=certificationAuthority)"

Note that the values for URI.1 and URI.2 should each be given on a single line.

The first URI defines a dynamic revocation list on a web server. Openswan will use the curl command to fetch this from the web server. The second URI uses LDAP, which is also fetched using the curl command, which has LDAP support. Note that if you store CRL information in OpenLDAP, you need to use the DER format and not the PEM format. The OpenSSL command can create CRLs in either format. It will use PEM by default. If you need to use DER, add the option -outform der to the OpenSSL commands specified earlier in the chapter. You will need to add the appropriate scripts to update the CRL files or LDAP entry yourself, for instance by using the scp command from the secure signing machine to the web server if your CRL file is on a web server. You can also put this information in a special CA connection section:

ca XeleranceCA cacert=caCert.pem auto=add

# the following lines are optional crluri=http://crl.xelerance.com/revoked.crl' crluri2="ldap:///O=Xelerance, C=CA?certificateRevocationList" ldaphost=ldap.xelerance.com

126

Chapter 5

Using separate CA connection sections, you can specify different CRL servers for different intermediate CA certificates.

Configuring CRL

There are two important options that change the behavior of dynamic CRL fetching. These options should be placed in the config setup section of ipsec.conf:

config setup crlcheckinterval=600 strictcrlpolicy=yes

The crlcheckinterval= period determines how often Openswan will try to fetch a new version of the CRL file. It will only try to fetch a new version if the CRL expires in a time shorter than twice the crlcheckinterval= time. Thus, if you make the CRL valid for a year, which you should never do, you will never see it try to fetch an updated version. A good CRL lifetime is something short.

The shorter you make it, the quicker you can revoke someone's certificate. However, you should make sure that the CRL does not expire. CRLs are not stored between restarts of Openswan, but are fetched again from the specified distribution points.

Openswan uses a default of strictcrlpolicy=no, meaning that if no valid CRL is found, warnings are logged, but connections are not rejected. In this mode, an expired CRL is also treated as a valid CRL, meaning only entries in the expired CRL that have been revoked will actually be treated as revoked. To strictly enforce CRL settings, set strictcrlpolicy=yes. Be aware that if your CRL then expires, no new incoming connections will be accepted. If you access your dynamic CRL over an IPsec tunnel, this also means you are completely dead in the water when that tunnel needs to rekey. Another effect is that at startup, the first few connections might be rejected because a valid CRL has not yet been fetched and loaded.

To view the status of the CRL, issue the following command:

# ipsec auto --listcrls

000

000 List of X.509 CRLs:

000

000 Apr 04 17:27:47 2005, revoked certs: 2

000 issuer: 'C=CA, ST=Ontario, L=Toronto, O=Xelerance, OU=Support Staff, CN=Xelerance Root CA, E=[e-mail]'

000 distPts: 'http://crl.xelerance.com/revoked.crl'

000 updates: this Mar 19 23:54:35 2005

000 next Apr 04 00:54:35 2005 warning (expired)

In this case you can see that the CRL has expired, and if crlstrictmode had been enabled, no new IPsec connections would be allowed. This command would also show any pending CRL transfer attempts.

127

X.509 Certificates

Online Certificate Status Protocol (OCSP)

Defined in RFC 2560, OCSP is an extension for dynamic CRL fetching. Instead of using a CRL, the gateway will now ask an OCSP server for information about a specific X.509 Certificate presented by a remote peer trying to initiate an IPsec connection. Based upon the answer of the OCSP server, Openswan will accept or reject the certificate. Like CRL responses, OCSP responses do not survive a reboot, and will be retrieved again from the OCSP server. OCSP is enabled in a separate CA section:

ca XeleranceCA cacert=caCert.pem

ocspuri=http://ocsp.xelerance.com:81

auto=add

The port number is arbitrary. You can manually load this CA connection using this command:

# ipsec auto --type ca --add XeleranceCA

You can also put options in the special ca %default section, which can also be used if there is only one CA certificate on the server. An example given is below:

ca %default ocspuri=http://ocsp.xelerance.com:81

You will need to run an OCSP server, in our example at ocsp.xelerance.com. The OpenSSL package contains an OCSP server. After creating a key and certificate for the OCSP server, just as they are generated for an IPsec host, the OCSP server can be started with the following commands:

# openssl ocsp -index index.txt -CA caCert.pem -port 81 -rkey ocspKey.pem -rsigner ocspCert.pem -resp_no_certs -nmin 60 -text

You will also need to place a copy of the OCSP public certificate (ocspCert.pem) on the VPN

gateway in the directory /etc/ipsec.d/OCSPcerts/.

It is strongly recommended not to run the OCSP server on the machine that has the CA private key used for signing certificates.

Additional commands for viewing		Description
and purging OCSP data
ipsec auto	--listocspcerts	List OCSP information
ipsec auto	--purgeocsp	Purge the OCSP cache and fetching requests

The OCSP patches have not yet been fully integrated into Openswan. Please take a look at the website for the latest information on OCSP support in Openswan.

128