Hi,
I am re-sending my answer from June 22 to this thread:
http://thread.gmane.org/gmane.network.openvpn.devel/3703
It must have somehow fallen deeply in your email boxes. ;-) The text below show
that the two certificates Jan
Just Keijser generated the days before could not be used on my Gentoo box.
Clearly, the problem is with Gentoo
install/my binaries and has nothing to do with the key and certificate creation.
Thanks,
Martin
--------------
Hi everybody,
so I tested the keys which Jan generated and did reproduce the problem again
on my Gentoo Linux build. It is related to the fact that I had on client:
tls-auth /home/janjust/rsa-test/ta.key 1
while on the server
tls-auth /home/janjust/rsa-test/ta.key 0
Jun 22 23:24:18 vrapenec openvpn[21646]: OpenVPN 2.1.0 i686-pc-linux-gnu [SSL]
[LZO2] [EPOLL] built on May 17 2010
Jun 22 23:24:18 vrapenec openvpn[21646]: NOTE: OpenVPN 2.1 requires
'--script-security 2' or higher to call user-defined scripts or executables
Jun 22 23:24:18 vrapenec openvpn[21646]: Control Channel Authentication: using
'keys/ta.key' as a OpenVPN static key file
Jun 22 23:24:18 vrapenec openvpn[21646]: Outgoing Control Channel
Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jun 22 23:24:18 vrapenec openvpn[21646]: Incoming Control Channel
Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jun 22 23:24:18 vrapenec openvpn[21646]: LZO compression initialized
Jun 22 23:24:18 vrapenec openvpn[21646]: Control Channel MTU parms [ L:1542
D:166 EF:66 EB:0 ET:0 EL:0 ]
Jun 22 23:24:18 vrapenec openvpn[21646]: Data Channel MTU parms [ L:1542 D:1450
EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Jun 22 23:24:18 vrapenec openvpn[21646]: Local Options hash (VER=V4): '504e774e'
Jun 22 23:24:18 vrapenec openvpn[21646]: Expected Remote Options hash (VER=V4):
'14168603'
Jun 22 23:24:18 vrapenec openvpn[21647]: NOTE: UID/GID downgrade will be
delayed because of --client, --pull, or --up-delay
Jun 22 23:24:18 vrapenec openvpn[21647]: Socket Buffers: R=[108544->131072]
S=[108544->131072]
Jun 22 23:24:18 vrapenec openvpn[21647]: UDPv4 link local: [undef]
Jun 22 23:24:18 vrapenec openvpn[21647]: UDPv4 link remote: XXX.XXX.XXX.XXX:1194
Jun 22 23:24:18 vrapenec openvpn[21647]: TLS: Initial packet from
XXX.XXX.XXX.XXX:1194, sid=2f11657e e78d6a4f
Jun 22 23:24:18 vrapenec openvpn[21647]: VERIFY ERROR: depth=0,
error=unsupported certificate purpose:
/C=NL/O=Test/CN=glaurung/emailAddress=janj...@xxxxx.nl
Jun 22 23:24:18 vrapenec openvpn[21647]: TLS_ERROR: BIO read tls_read_plaintext
error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed
Jun 22 23:24:18 vrapenec openvpn[21647]: TLS Error: TLS object -> incoming
plaintext read error
Jun 22 23:24:18 vrapenec openvpn[21647]: TLS Error: TLS handshake failed
Jun 22 23:24:18 vrapenec openvpn[21647]: TCP/UDP: Closing socket
Jun 22 23:24:18 vrapenec openvpn[21647]: SIGUSR1[soft,tls-error] received,
process restarting
Jun 22 23:24:18 vrapenec openvpn[21647]: Restart pause, 2 second(s)
Jun 22 23:24:20 vrapenec openvpn[21647]: NOTE: OpenVPN 2.1 requires
'--script-security 2' or higher to call user-defined scripts or executables
Jun 22 23:24:20 vrapenec openvpn[21647]: Re-using SSL/TLS context
Jun 22 23:24:20 vrapenec openvpn[21647]: LZO compression initialized
Jun 22 23:24:20 vrapenec openvpn[21647]: Control Channel MTU parms [ L:1542
D:166 EF:66 EB:0 ET:0 EL:0 ]
Jun 22 23:24:20 vrapenec openvpn[21647]: Data Channel MTU parms [ L:1542 D:1450
EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Jun 22 23:24:20 vrapenec openvpn[21647]: Local Options hash (VER=V4): '504e774e'
Jun 22 23:24:20 vrapenec openvpn[21647]: Expected Remote Options hash (VER=V4):
'14168603'
Jun 22 23:24:20 vrapenec openvpn[21647]: Socket Buffers: R=[108544->131072]
S=[108544->131072]
Jun 22 23:24:20 vrapenec openvpn[21647]: UDPv4 link local: [undef]
Jun 22 23:24:20 vrapenec openvpn[21647]: UDPv4 link remote: XXX.XXX.XXX.XXX:1194
Jun 22 23:24:20 vrapenec openvpn[21647]: TLS: Initial packet from
XXX.XXX.XXX.XXX:1194, sid=350eb404 4c110b32
Jun 22 23:24:20 vrapenec openvpn[21647]: VERIFY ERROR: depth=0,
error=unsupported certificate purpose:
/C=NL/O=Test/CN=glaurung/emailAddress=janj...@xxxxx.nl
Jun 22 23:24:20 vrapenec openvpn[21647]: TLS_ERROR: BIO read tls_read_plaintext
error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed
Jun 22 23:24:20 vrapenec openvpn[21647]: TLS Error: TLS object -> incoming
plaintext read error
Jun 22 23:24:20 vrapenec openvpn[21647]: TLS Error: TLS handshake failed
Jun 22 23:24:20 vrapenec openvpn[21647]: TCP/UDP: Closing socket
Jun 22 23:24:20 vrapenec openvpn[21647]: SIGUSR1[soft,tls-error] received,
process restarting
Jun 22 23:24:20 vrapenec openvpn[21647]: Restart pause, 2 second(s)
It is unclear to me according to the comments in the client.conf file what is
the number after "ta.key" doing (some version number?) and at the moment am not
looking it up in the docs. ;)
If I set the number on client also to "0" (like on the server) I get:
Jun 22 23:19:25 vrapenec openvpn[21597]: OpenVPN 2.1.0 i686-pc-linux-gnu [SSL]
[LZO2] [EPOLL] built on May 17 2010
Jun 22 23:19:25 vrapenec openvpn[21597]: NOTE: OpenVPN 2.1 requires
'--script-security 2' or higher to call user-defined scripts or executables
Jun 22 23:19:25 vrapenec openvpn[21597]: Control Channel Authentication: using
'keys/ta.key' as a OpenVPN static key file
Jun 22 23:19:25 vrapenec openvpn[21597]: Outgoing Control Channel
Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jun 22 23:19:25 vrapenec openvpn[21597]: Incoming Control Channel
Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jun 22 23:19:25 vrapenec openvpn[21597]: LZO compression initialized
Jun 22 23:19:25 vrapenec openvpn[21597]: Control Channel MTU parms [ L:1542
D:166 EF:66 EB:0 ET:0 EL:0 ]
Jun 22 23:19:25 vrapenec openvpn[21597]: Data Channel MTU parms [ L:1542 D:1450
EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Jun 22 23:19:25 vrapenec openvpn[21597]: Local Options hash (VER=V4): '79fd358d'
Jun 22 23:19:25 vrapenec openvpn[21597]: Expected Remote Options hash (VER=V4):
'd81d562e'
Jun 22 23:19:25 vrapenec openvpn[21598]: NOTE: UID/GID downgrade will be
delayed because of --client, --pull, or --up-delay
Jun 22 23:19:25 vrapenec openvpn[21598]: Socket Buffers: R=[108544->131072]
S=[108544->131072]
Jun 22 23:19:25 vrapenec openvpn[21598]: UDPv4 link local: [undef]
Jun 22 23:19:25 vrapenec openvpn[21598]: UDPv4 link remote: XXX.XXX.XXX.XXX:1194
but no VPN is started (note the "undef" value, and can confirm that with
ifconfig -a):
tunl0 Link encap:IPIP Tunnel HWaddr
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Hope this helps,
Martin
> janj...@xxxxx.nl wrote:
> attached are the certs I generated yesterday. The server and client
> configuration I used were very minimal:
>
> server.conf:
>
> tls-server
> proto udp
> port 1194
> dev tun
> server 192.168.200.0 255.255.248.0
> ca /home/janjust/rsa-test/test-ca.crt
> cert /home/janjust/rsa-test/server.crt
> key /home/janjust/rsa-test/server.key
> dh /home/janjust/rsa-test/dh1024.pem
> tls-auth /home/janjust/rsa-test/ta.key 0
> persist-key
> persist-tun
> keepalive 10 60
> remote-cert-tls client
>
> client.conf:
>
> client
> proto udp
> remote openvpnserver
> port 1194
> dev tun
> nobind
> ca /home/janjust/rsa-test/test-ca.crt
> cert /home/janjust/rsa-test/client.crt
> key /home/janjust/rsa-test/client.key
> tls-auth /home/janjust/rsa-test/ta.key 0
> remote-cert-tls server
Martin Mokrejs wrote:
> David Sommerseth wrote:
>> On 09/06/10 23:56, Martin MOKREJ` wrote:
>>> The patches in Gentoo I for example here:
>
> I use Gentoo, I believed that was a "typo" of Jan and did not comment
> on that.
>
>
>>> Please improve the openVPN docs. Further, isn't it possible to
>>> provide two openssl.cf files, one for client and the other for
>>> server, and fill-in more default values. I never know where to place
>>> FQDN, where to place "server", "client", and you saw in my proposed
>>> patch that I had to invent even more.
>>
>> The documentation needs to be reviewed, to be sure it does provide
>> accurate information. Having that said, it doesn't seem to be that many
>> who struggles with this on the ##openvpn IRC channel. I admit I've not
>> paid too much attention to the discussions there the last few weeks, but
>> this (VERIFY KU ERROR) is not on the "top 10" trouble list, afaik.
>
> I believe it is an issue. I posted how I generated the certificates and
> expect that somebody would have already told me I did answer the questionaree
> in a wrong way. For sure, the shell scripts can run something like
> "openssl x509 -in cert.crt -text" and verify that the certificate will
> be usable for client or server only. The user would not have to transfer it
> to the server to realize it is going to refuse it.
> Here you can see how I generated the certificates:
> http://rt.openssl.org/Ticket/Display.html?id=2268&user=guest&pass=guest
> It's too late here but I think instead of teh word "client" I used word
> "server". But, if the server key/cert cannot be created by the build-ca
> script or sign-req, then we found why I maybe had to tweak the openssl.cf
> file. ;-)
>
> My apologies if I followed a wrong manual, I think I followed some on your
> site but anyway, I am sure you you check more thoroughly what I did and
> make the scripts more fool-proof.
>
> Once I get physically to an old Sun Solaris 2.6 machine I will turn it on
> and check that they run smoothly with those "remove bashism" patches. ;-)
> In 2-3 weeks.
>
>
>> But on the other hand, most easy-rsa users do also make use of the
>> ./build-key-server and ./build-key{,-pass,-pkcs12} scripts. It might be
>> an issue related to ./sign-req.
>>
>> I strongly do not recommend having more openssl.cnf files. It is
>> possible to use one file, which makes the maintenance easier in the long
>> run. The ./pkitool script should take care of providing the needed
>> "tweaks" to separate between client and server certificates.
>
> BTW, what I do not like that I have to have write perms into
> /some/blah/openvpn/easy-rsa/. It is counterintuitive to have to do as root:
>
> # cd /some/blah/openvpn/easy-rsa/
> # ./build-ca
>
> I believe the scripts can be called from any cwd() and the keys/ subdirs
> can be made in there. Sure, I have no problem doing
> ". /some/blah/openvpn/easy-rsa/openssl.cf" before executing
> /some/blah/openvpn/easy-rsa/build-ca. ;-) Just some clues.
>
>>
>> For a similar script based version which might work better, take a look
>> at ssl-admin <http://www.secure-computing.net/wiki/index.php/Ssl-admin>.
>
> Will look later, thanks.
>
>>
>>
>> I also noticed that Ubuntu was mentioned in the thread. It might not be
>> directly related, but if you have an Ubuntu OpenVPN 2.1_rc7 - rc11
>> installation in use, beware that these versions do have some patches
>> which makes it incompatible with other versions. And the failure in
>> this case is not obvious. So, if possible, upgrade to OpenVPN
>> 2.1.0/2.1.1 on client and server.
>
> No, as I posted, the only patches applied on my setup were those two,
> and the contents of the whole files/ subdir you have just inspected
> through some Gentoo mirror.
>
> Time for sleep here, ;-)
> Martin
