X.509 Certificates

STATE_MAIN_I2 to state		STATE_MAIN_I3
Feb 28	23:30:38 xsable	pluto[24759]: "x509" #3: Peer ID is ID_DER_ASN1_DN:
'C=CA,	ST=Ontario, L=Toronto, O=Xelerance, OU=Writers, CN=east.xelerance.com,
E=[e-mail]'
Feb 28	23:30:38 xsable	pluto[24759]: "x509" #3: end certificate with identical
subject and issuer not		accepted
Feb 28	23:30:38 xsable	pluto[24759]: "x509" #3: X.509 certificate rejected
Feb 28	23:30:38 xsable	pluto[24759]: "x509" #3: transition from state
STATE_MAIN_I3 to state		STATE_MAIN_I4
Feb 28	23:30:38 xsable	pluto[24759]: "x509" #3: ISAKMP SA established
Feb 28	23:30:38 xsable	pluto[24759]: "x509" #4: initiating Quick Mode
RSASIG+ENCRYPT+TUNNEL+PFS+UP {using isakmp#3}
Feb 28	23:30:38 xsable	pluto[24759]: "x509" #4: transition from state
STATE_QUICK_I1 to state STATE_QUICK_I2
Feb 28	23:30:38 xsable	pluto[24759]: "x509" #4: sent QI2, IPsec SA established

{ESP=>0x7f55f371 <0xe26d3875}

Openswan versions up to at least 2.3.0 give the error message you can see above about rejecting a certificate with identical subject and issuer when explicitly loading self-signed certificates without a CA, even though the connection works fine. This message actually comes from when a CA is used, and it is found that the CA's CN= is the same as the CN= which it signed for.

The error message results from verification problems within the X.509 parser, which cannot clearly differentiate the CA and the host certificate when they have the same name, and the host certificate could be used to sign another host certificate. Therefore these certificates are rejected. Of course, self-signed certificates do have this property too, and that is why we see this error message. However, the message is misleading as our certificates, which are explicitly loaded, are in fact not rejected.

Using a Certificate Authority

When using a CA you can match many connections, usually roadwarriors, in a single connection. The trust now comes from the fact that we trust that the CA has only signed (and not revoked) valid client certificates. If an incoming connection presents a certificate with a public key that was signed by a CA that we trust, we allow the connection. We can limit the allowed connections based on the DN.

conn west-roadwarriors left=193.110.157.81 leftcert=/etc/ipsec.d/certs/west.pem rightrsasigkey=%cert

right=%any

rightid="C=CA, O=Xelerance, OU=bofh, CN=*" auto=add

Using pattern matching on the DN in the rightid= you can implement access restrictions. You could use different conn definitions with a different leftsubnet= or even a leftprotoport= to give very specific access to groups or individuals. You can also make special connections using a leftsubnet= that points to a network printer. This might require careful planning of the RDNs in your certificates. You might want to add an extra OU for a certain access control, or use one of the less frequently used RDNs.

120

Chapter 5

conn sales-printer leftcert=west.pem leftsubnet=10.0.2.2/32

rightid="C=CA, O=Xelerance, OU=Sales, CN=*" also=base-conn

Some more examples of using the DN for access control:

#Match the entire organisation rightid="C=CA, O=Xelerance, OU=*, CN=*"

#Match a single person

rightid="C=CA, O=Xelerance, OU=bofh, CN=Jane Jones

# Match people from one office

rightid="C=CA, O=Xelerance, L=Ottawa, OU=*, CN=*"

Remember that you cannot leave out an RDN. If you do not care about the content of a certain RDN, match it with *.

You need to have an equal number of RDNs (of the same types) in your DN for the match to succeed.

Using Multiple CAs

When organizations get bigger, the task of handing out signed certificates is usually broken up and handled by different branches or departments. You can use an intermediary CA to address this. The root CA creates and signs two or more intermediary CAs. They can be given to the different departments, who can then create and sign certificates. On the VPN server that serves the entire company, you can create different conns for different departments to restrict access to the department's network alone:

conn west-roadwarriors-all left=193.110.157.81 leftsubnet=192.168.1.0/24 leftcert=west.pem right=%any rightrsasigkey=%cert

rightca="C=CA, O=Xelerance, CN=Root CA" auto=add

conn west-roadwarriors-development left=193.110.157.81 leftsubnet=10.0.1.0/24 right=%any rightrsasigkey=%cert

rightca="C=CA, O=Xelerance, CN=Development CA" auto=add

conn west-roadwarriors-support left=193.110.157.81 leftsubnet=10.0.2.0/24 right=%any rightrsasigkey=%cert

rightca="C=CA, O=Xelerance, CN=Support CA" auto=add

121

roadwarriors-all

X.509 Certificates

In this configuration, everyone can access the 192.168.1.0/24 network, for example the DMZ containing the email and web servers, but the support staff cannot get onto the developer network and vice versa. Of course you can further limit or grant access to groups or individuals by combining matching of rightca= and rightid=. The corresponding entry for the conn west-

on the Openswan roadwarrior would look like this:

conn west-roadwarriors-all left=%defaultroute leftcert=east.pem right=193.110.157.81 righttsubnet=192.168.1.0/24

rightid=" C=CA, O=Xelerance, CN=Root CA, CN=west.xelerance.com, E=[e-mail]"

#rightca="C=CA, O=Xelerance, CN=Root CA" auto=add

Sending and Receiving Certificate Information

When no rightca= is specified, then all certificates signed by any of the loaded CAs from /etc/ipsec.d/cacerts/ will be allowed. Though it is possible to specify a leftca=, this is usually not needed since this value will be taken from the CA that signed the leftcert='s host certificate. Using rightca=%same only allows certificates that are signed by the same CA that signed the leftcert=, though usually in such situations, you will only have one CA in /etc/ipsec.d/cacerts/ listed anyway, so this option can usually be omitted as well.

Normally, the client (or rather, the initiator) sends its CA as part of the IKE exchange to indicate which trust chain applies to the current connection. From a security point of view, a server (responder) should not broadcast all the valid CAs it trusts to the (so far) unauthenticated client. This behavior can be fine-tuned using the leftsendcert= parameter:

leftsendcert parameter	Description
leftsendcert=ifasked	Sent certificate if asked
leftsendcert=no	Never sent certificate
leftsendcert=never
leftsendcert=yes	Always sent certificate
leftsendcert=always

Ideally, you should use the default ifasked option, but this breaks compatibility with some vendors, such as Cisco and Safenet. In those cases, you should set this option to always.

Creating your own CA using OpenSSL

The following command can be used to create your own Certificate Authority:

# openssl req -x509 -days 3650 -newkey rsa:1024 -keyout caKey.pem -out caCert.pem

Generating a 1024 bit RSA private key

...............

writing new private key to 'caKey.pem'

122