Re: [Openvpn-devel] openvpn-2.1.0-r1: easy-rsa tools creates broken client CERTs unusable for TLS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/06/10 23:56, Martin MOKREJŠ wrote:
> The patches in Gentoo I for example here:
> http://mirror.averse.net/gentoo-portage/net-misc/openvpn/files/
>
>>> On the client:
>>> I use net-misc/openvpn-2.1.0-r1, I see there are two patches applying to
>>> my systems (no IPv6 patch):
>>> epatch "${FILESDIR}/${PN}-2.1_rc13-peercred.patch"
>>> epatch "${FILESDIR}/${PN}-2.1_rc20-pkcs11.patch"
[...snip...]
>
> Look at the two patches, they should probably go into you tree anyways if
> they are not just fixing some compilation/layout issues.
>
Those patches are clean, and not related at all to this issue at all.
The peercred patch has been adopted and included into the
openvpn-testing.git tree.
- -
commit 48045ace0541ec39f9c5003c0c37a23e1651f39d
Author: David Sommerseth
List-Post: openvpn-devel@lists.sourceforge.net
Date: Wed Mar 10 11:45:04 2010 +0100
On TARGET_LINUX define _GNU_SOURCE if not defined
This is to include peercred support on hosts where _GNU_SOURCE is
not defined by default. This issue has been found on Gentoo with
glibc-2.8.
The solution was discussed on the IRC meeting March 4, 2010
in #openvpn-discussions.
Signed-off-by: David Sommerseth
Acked-by: James Yonan
- -
[...snip...]
> 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.
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.
For a similar script based version which might work better, take a look
at ssl-admin .
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.
kind regards,
David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkwQFssACgkQDC186MBRfrr0/wCdEhjMNJgNkzNEQsZRKrxghlWv
f4MAn2yLisOUr+a+eN7uzJjID1D6L4Fz
=QH6W
-END PGP SIGNATURE-
Re: [Openvpn-devel] openvpn-2.1.0-r1: easy-rsa tools creates broken client CERTs unusable for TLS
Hi,
Martin Mokrejs wrote:
Hi,
David Sommerseth wrote:
On 08/06/10 18:24, Martin Mokrejs wrote:
Hi,
I had a look into the original bug report I sent and the summary is this:
at some version openvpn implemented a more strict check for certificate
values and if teh cjeck fails one yields "unsupported certificate purpose"
message.
I figured out that few more allowed values have to be included in the
certificate so that openVPN does not complain anymore. Basically, the patch
synchronizes the current openVPN behavior with the easy-rsa/ tools.
Is it clearer now? I attached to the bugreport at Gentoo an older version
of the patch to hopefully help you better with understanding what I tried.
What I believe should happen that somebody documents better what requirements
are for the server/client certifices in openVPN. The patch(es) show what
fields you should describe in docs and some version of the patch be committed
over easy-rsa/openssl.cf as well (or loosen the checks back in openVPN sources).
Martin
Ahoj Martin,
Thanks a lot for your patch and your investigations! That is very much
appreciated!
Your issues was discussed in the last developers meeting (Thu June 3rd)
and it is not clear to us why you experiences this problem. I believe
Jan Just Keiser told that he had quite recently tested out easy-rsa-2.0
and he had no issues at all.
I am also running a OpenVPN server on a Gentoo box, even though on this
box I'm using TinyCA, so it is not directly comparable. Anyhow, the
X509v3 extensions are not that far away from what I do see easy-rsa-2.0
should normally set:
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Client, S/MIME, Object Signing
I do see however that you are having mentioned Netscape Cert Type in
your bug report.
Could this be related to some trickery patches Gentoo does to OpenVPN or
OpenSSL? Or that it is related to the OpenSSL version?
I have no idea what is patched on Gentoo and why, but I found lots of those
"unsupported certificate purpose" reports through Google, with very few real
answers. I don't believe it is Gentoo specific.
On the client:
I use net-misc/openvpn-2.1.0-r1, I see there are two patches applying to
my systems (no IPv6 patch):
epatch "${FILESDIR}/${PN}-2.1_rc13-peercred.patch"
epatch "${FILESDIR}/${PN}-2.1_rc20-pkcs11.patch"
I use dev-libs/openssl-0.9.8n.
On the server:
net-misc/openvpn-2.1.0-r1
dev-libs/openssl-0.9.8n
Would you mind sharing your configuration files and information about
the OpenSSL version you are using?
The client and server configs are attached.
here's what I just did:
- downloaded openssl 0.9.8n
- ran
./config shared
make
on it
- reconfigured openvpn 2.1.1 to make use of this version of openssl
- ran
./configure ...
make clean
make
on it
- set up a new CA + server cert + client server using umodified easy-rsa
2.0 scripts from the openvpn distro
- set up client and server config files pretty much like the ones attached
Result: Both server and client start without problems. I can even add
remote-cert-tls client
to the server config and the thing still starts. In other words: I
cannot reproduce the bug.
When I took a closer look at the original Ubuntu bug report it suggests
that the original server cert was not built correctly:
May 17 14:33:20 vrapenec openvpn[21477]: ++ Certificate has key usage 0080,
expects 00a0
May 17 14:33:20 vrapenec openvpn[21477]: ++ Certificate has key usage 0080,
expects 0088
May 17 14:33:20 vrapenec openvpn[21477]: VERIFY KU ERROR
the key usage found (0080) is for a *client* certificate, not a server certificate.
The server certificate should eku '00a0' set, as the log file later on in the bug report
shows.
Martin, can you
- use the stock easy-rsa scripts (i.e. not the ones from ubuntu)
- create a new CA and client server and server cert (build-ca, build-key
, build-key-server)
- rerun your test
If this still fails then Ubuntu may have added a patch that broke something.
cheers,
JJK
Hi,
We discussed your bug report in last week's public IRC meeting:
In a nutshell, we had difficulties understanding what is required to
reproduce this bug. Unfortunately the discussion logs were lost so I
can't be any more specific. Would you like help us understand this issue
by chatting with our devs on #openvpn-de...@irc.freenode.net? Or
alternatively by sending mail to openvpn-devel mailinglist:
All the best,
-- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
Martin Mokrejs wrote:
Hi,
I think the easy-rsa/openssl.cnf file should be modified so thet client
CERTs would match current openVPN expectations. Please see my bug report
at
Re: [Openvpn-devel] openvpn-2.1.0-r1: easy-rsa tools creates broken client CERTs unusable for TLS
Hi,
David Sommerseth wrote:
> On 08/06/10 18:24, Martin Mokrejs wrote:
>> Hi,
>> I had a look into the original bug report I sent and the summary is this:
>> at some version openvpn implemented a more strict check for certificate
>> values and if teh cjeck fails one yields "unsupported certificate purpose"
>> message.
>
>> I figured out that few more allowed values have to be included in the
>> certificate so that openVPN does not complain anymore. Basically, the patch
>> synchronizes the current openVPN behavior with the easy-rsa/ tools.
>
>> Is it clearer now? I attached to the bugreport at Gentoo an older version
>> of the patch to hopefully help you better with understanding what I tried.
>> What I believe should happen that somebody documents better what requirements
>> are for the server/client certifices in openVPN. The patch(es) show what
>> fields you should describe in docs and some version of the patch be committed
>> over easy-rsa/openssl.cf as well (or loosen the checks back in openVPN
>> sources).
>> Martin
>
> Ahoj Martin,
>
> Thanks a lot for your patch and your investigations! That is very much
> appreciated!
>
> Your issues was discussed in the last developers meeting (Thu June 3rd)
> and it is not clear to us why you experiences this problem. I believe
> Jan Just Keiser told that he had quite recently tested out easy-rsa-2.0
> and he had no issues at all.
>
> I am also running a OpenVPN server on a Gentoo box, even though on this
> box I'm using TinyCA, so it is not directly comparable. Anyhow, the
> X509v3 extensions are not that far away from what I do see easy-rsa-2.0
> should normally set:
>
> X509v3 extensions:
> X509v3 Basic Constraints:
> CA:FALSE
> Netscape Cert Type:
> SSL Client, S/MIME, Object Signing
>
> I do see however that you are having mentioned Netscape Cert Type in
> your bug report.
>
> Could this be related to some trickery patches Gentoo does to OpenVPN or
> OpenSSL? Or that it is related to the OpenSSL version?
I have no idea what is patched on Gentoo and why, but I found lots of those
"unsupported certificate purpose" reports through Google, with very few real
answers. I don't believe it is Gentoo specific.
On the client:
I use net-misc/openvpn-2.1.0-r1, I see there are two patches applying to
my systems (no IPv6 patch):
epatch "${FILESDIR}/${PN}-2.1_rc13-peercred.patch"
epatch "${FILESDIR}/${PN}-2.1_rc20-pkcs11.patch"
I use dev-libs/openssl-0.9.8n.
On the server:
net-misc/openvpn-2.1.0-r1
dev-libs/openssl-0.9.8n
>
> Would you mind sharing your configuration files and information about
> the OpenSSL version you are using?
The client and server configs are attached.
Thanks,
Martin
>
>
> kind regards,
>
> David Sommerseth
>
>
>>> Hi,
>>>
>>> We discussed your bug report in last week's public IRC meeting:
>>>
>>>
>>>
>>> In a nutshell, we had difficulties understanding what is required to
>>> reproduce this bug. Unfortunately the discussion logs were lost so I
>>> can't be any more specific. Would you like help us understand this issue
>>> by chatting with our devs on #openvpn-de...@irc.freenode.net? Or
>>> alternatively by sending mail to openvpn-devel mailinglist:
>>>
>>>
>>>
>>> All the best,
>>>
>>> -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode
>>> net: mattock
>
>>> Martin Mokrejs wrote:
Hi,
I think the easy-rsa/openssl.cnf file should be modified so thet client
CERTs would match current openVPN expectations. Please see my bug report
at http://bugs.gentoo.org/show_bug.cgi?id=320171 . For convenience, I am
attaching the patch here. Did I get it right what has to be done? Would
someone fix the HOWTO and FAQ documentation to describe the keyUsage
fields and what is actually required for what? There is too many hit
in google for "unsupported certificate purpose". ;)
>
>> --
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit. See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> ___
>> Openvpn-devel mailing list
>> Openvpn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
>
##
# Sample client-side OpenVPN 2.0 config file #
# for connecting to multi-client server. #
##
# This configuration can be used by multiple #
# clients, however each client should have #
# its own cert and key files.#
##
# On Windows, you might want to rename this #
# file so
