Re: [Openvpn-devel] openvpn-2.1.0-r1: easy-rsa tools creates broken client CERTs unusable for TLS
Martin Mokrejs wrote: > Hi Jan, > I am sorry for the long delay, I was away some days and then just overloaded > by other duties. I have increased the verbosity on both client and server. > I see some weird IP address on the server in the log: 94.112.118.14 is not > my physical eth0 IP address nor the virtual network to be created by openvpn. Eh, well it is my clients external IP, I forgot is has changed recently. M.
Re: [Openvpn-devel] openvpn-2.1.0-r1: easy-rsa tools creates broken client CERTs unusable for TLS
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...@x.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=guest=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 o
Re: [Openvpn-devel] openvpn-2.1.0-r1: easy-rsa tools creates broken client CERTs unusable for TLS
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=guest=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 .
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
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:
>>>
>>> <http://thread.gmane.org/gmane.network.openvpn.devel/3748>
>>>
>>> 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:
>>>
>>> <http://sourceforge.net/mail/?group_id=48978>
>>>
>>> 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
>> __
Re: [Openvpn-devel] openvpn-2.1.0-r1: easy-rsa tools creates broken client CERTs unusable for TLS
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 > Hi, > > We discussed your bug report in last week's public IRC meeting: > > <http://thread.gmane.org/gmane.network.openvpn.devel/3748> > > 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: > > <http://sourceforge.net/mail/?group_id=48978> > > 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". ;)
[Openvpn-devel] openvpn-2.1.0-r1: easy-rsa tools creates broken client CERTs unusable for TLS
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". ;) Regards Martin --- /usr/share/openvpn/easy-rsa/openssl.cnf 2010-05-17 14:51:02.0 +0200 +++ openssl.cnf 2010-05-17 14:36:05.0 +0200 @@ -173,7 +173,7 @@ # the certificate can be used for anything *except* object signing. # This is OK for an SSL server. -# nsCertType = server +# nsCertType = client, server, email # For an object signing certificate this would be used. # nsCertType = objsign @@ -182,7 +182,7 @@ # nsCertType = client, email # and for everything including object signing: -# nsCertType = client, email, objsign +# nsCertType = server, client, email, objsign # This is typical in keyUsage for a client certificate. # keyUsage = nonRepudiation, digitalSignature, keyEncipherment @@ -193,8 +193,9 @@ # PKIX recommendations harmless if included in all certificates. subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer:always -extendedKeyUsage=clientAuth -keyUsage = digitalSignature +extendedKeyUsage=clientAuth,serverAuth +#extendedKeyUsage=clientAuth,serverAuth,ipsecUser,ipsecTunnel,ipsecEndSystem +keyUsage = digitalSignature, keyEncipherment # This stuff is for subjectAltName and issuerAltname. # Import the email address.
