[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