[Openswan Users] PSK works, certificates not

Arno Lehmann al at its-lehmann.de
Tue Jul 17 18:04:26 EDT 2007


Hi,

17.07.2007 19:24,, Paul Wouters wrote::
> On Tue, 17 Jul 2007, Arno Lehmann wrote:
> 
>> Quite basic at the moment:
>> I have an internal network, 192.168.0.0/24, where I run a server that
>> will become a VPN gateway. This is "balrog" at 192.168.0.22.
> 
>> A test client "phoenix" is at .88. This machine runs MS Windows Vista
>> business.
> 
>> conn intern-cert
>>          authby=rsasig
>>          rightrsasigkey=%cert
>>          leftcert=ITS-VPN.pem
>>          left=192.168.0.22
>>          leftprotoport=17/1701
>>          right=%any
>>          rightprotoport=17/1701
>>          rightsubnet=vhost:%no,%priv
>>          rightca=%same
>>          auto=add
>>
>> (the defaults are unchanged from the PSK setup, and the connection
>> itself is also similar to the working PSK one.
>>
>> I created a (sub) CA (I'm using tinyCA for other certificate handling
>> already) and created two certificates, one for the VPN server, and one
>> for the windows client.
>>
>> I packaged the windows one as a pkcs12 file and installed it on that
>> machine.
> 
> How did you install it? Double clicking won't work properly.

I installed it via msc, using the Certificates (this is a german 
version, so the terminology might be slightly different) snap-in, all 
tasks..., import... dialog.

>> When I keep the gateway certificate protected by a password, and have
>> a line like ": RSA <keyfile> "password" in ipsec.secrets, I get these
>> messages:
>>
>>> Jul 17 01:18:05 balrog pluto[13311]: loading secrets from "/etc/ipsec.secrets"
>>> Jul 17 01:18:05 balrog pluto[13311]:   could not open private key file '/etc/ipsec.d/private/ITS-VPN.pem'
>>> Jul 17 01:18:05 balrog pluto[13311]: "/etc/ipsec.secrets" line 14: error loading RSA private key file
>>> Jul 17 01:18:05 balrog ipsec__plutorun: 003 "/etc/ipsec.secrets" line 14: error loading RSA private key file
> 
> that's odd. Are you using any odd characters in the secret?

No... just my usual password for test setups of all sorts of stuff, 
which is astonishing similar to "asdfgh" or "nhzbgt" :-)

>> If I unlock the key file (and comment out the line in ipsec.secrets),
>> I get no messages in the log.
> 
> You still need to put the keyfile in there, just leave out the "password" section.

Well, I got this solved... that was a layer 8 error :-)

> You can see with ipsec auto --listall what x509 bits have been loaded by pluto.

That works:
> balrog:~ # ipsec auto --listall
> 000
> 000 List of Public Keys:
> 000
> 000 Jul 17 11:39:30 2007, 4096 RSA Key AwEAAfYjK, until Jul 16 11:04:36 2008 ok
> 000        ID_USER_FQDN 'al at qits-lehmann.de'
> 000        Issuer 'C=DE, L=Osnabrueck, O=IT-Service Lehmann, OU=Network, CN=VPN'
> 000 Jul 17 11:39:30 2007, 4096 RSA Key AwEAAfYjK, until Jul 16 11:04:36 2008 ok
> 000        ID_DER_ASN1_DN 'C=DE, L=Osnabrueck, O=IT-Service Lehmann, OU=Network, CN=IT-S Lehmann VPN, E=al at qits-lehmann.de'
> 000        Issuer 'C=DE, L=Osnabrueck, O=IT-Service Lehmann, OU=Network, CN=VPN'
> 000

Do I correctly assume that this key can be correlated to certificates 
by its ID_USER_FQDN as well as its ID_DER_ASN1_DN?

> 000 List of X.509 End Certificates:
> 000
> 000 Jul 17 11:39:30 2007, count: 1
> 000        subject: 'C=DE, L=Osnabrueck, O=IT-Service Lehmann, OU=Network, CN=IT-S Lehmann VPN, E=al at qits-lehmann.de'
> 000        issuer:  'C=DE, L=Osnabrueck, O=IT-Service Lehmann, OU=Network, CN=VPN'
> 000        serial:   01
> 000        pubkey:   4096 RSA Key AwEAAfYjK, has private key
> 000        validity: not before Jul 17 11:04:36 2007 ok
> 000                  not after  Jul 16 11:04:36 2008 ok
> 000        subjkey:  cd:1a:3d:23:f7:1b:43:ac:8e:47:80:0f:db:17:48:09:60:d0:cb:5a
> 000        authkey:  a0:2e:c6:15:3e:a5:7d:6f:73:3b:ab:82:46:39:79:52:20:3d:fb:87
> 000        aserial:  06
> 000
> 000 List of X.509 CA Certificates:
> 000
> 000 Jul 17 11:39:30 2007, count: 1
> 000        subject: 'C=DE, L=Osnabrueck, O=IT-Service Lehmann, OU=Network, CN=VPN'
> 000        issuer:  'C=DE, L=Osnabrueck, O=IT-Service Lehmann, OU=CA, CN=IT-Service Lehmann CA, E=al at its-lehmann.de'
> 000        serial:   06
> 000        pubkey:   4096 RSA Key AwEAAbL7c
> 000        validity: not before Jul 17 01:03:40 2007 ok
> 000                  not after  Feb 14 00:03:40 2017 ok
> 000        subjkey:  a0:2e:c6:15:3e:a5:7d:6f:73:3b:ab:82:46:39:79:52:20:3d:fb:87
> 000        authkey:  42:8b:55:21:32:c8:2a:18:25:1c:d3:3e:8a:de:ac:0e:22:c9:c3:29
> 000        aserial:  00


Note that these data is not which I used for testing yesterday, but 
still doesn't work.

>> The malformed payload message is, as far as I understand after much
>> reading, more or less only an artifact of an unencrypted message sent
>> because encryption could not be established.
> 
> Yes, windows is bad in that way.

My limited knowledge of IPsec et al doesn't tell me how that could be 
handled better... I assume that, at this point in the IPsec 
conversation, the server already works in "encrypted mode" and has to 
interpret all data according to its decrytption rules. The client 
then, when it decides it can't use encryption, simply has no way of 
transmitting a valid response. (I'm sure this has been discussed among 
the people actually coding IPsec stacks, but currently I don not want 
to learn about these details :-)

Arno

> Paul

-- 
Arno Lehmann
IT-Service Lehmann
www.its-lehmann.de


More information about the Users mailing list