[SRU] openvpn2.1~rc7 fails to pick up the CN of certificates

Hi.

If possible, do you have the link to the mailing list archives where this was discussed. Furthermore, do you have some steps I could use to replicate the problem?

Thanks

Hi,

The mailing list archive is http://sourceforge.net/mailarchive/forum.php?forum_name=openvpn-users but it's not been updated with our post yet. However, a copy of the conversation is at http://pastebin.127001.org/223

That mail has our config, but any attempt to use client-specific configs (ccd) and x509 certificates should fail. For that matter, logging using x509 certicates should show each client as UNDEF instead of the proper CN.

Suggesting this for a backport into Hardy.

Actually, this should be an SRU. I am investigating this process.

Hi,

Would it be possible to help test this SRU by using my PPA.

deb http://ppa.launchpad.net/stefanlsd/ubuntu intrepid main

Contains openvpn_2.1~rc7-1ubuntu3.4~ppa1 which is the following change

 ssl.c: applied fix from upstream to fix extract_x509_field_ssl
    where the extraction would fail on the first field of
    the subject name.

Does this fix your error? If not, it might be another patch they did. I am also attaching the openvpn SVN log so if this doesn't work, we can more accurately identify your error and find the correct patch.

Thanks
Stefan

Hi,

This resolves the issue and CNs are picked up.

Thanks

Please consider the attached debdiff to resolve this issue with openvpn-2.1~rc7.

This bug will affect all users using x509 certificates and the ccd function of openvpn.

This bug has been resolved by upstream in Intrepid has it was fixed in openvpn-2.1~rc8 and Intrepid now includes openvpn-2.1~rc9.

The discussion with more details about this bug can be found on the openvpn mailing list when the user reported.

http://sourceforge.net/mailarchive/forum.php?thread_name=f80b41f3a44c384046621bc3af9919a1%40127001.org&forum_name=openvpn-users

Already fixed for intrepid.

Hi Stefan,

Thanks for the patch I made a slight change to your debdiff and uploaded it to hardy-proposed. However since openvpn is in main, You have to subscribe the ubuntu-sru team whch I will do as well.

Thanks
chuck

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Any testers on this one?

Stefan / Frymaster :
Could you provide a simple test case so that we can reproduce the bug and verify it is fixed ?
The pastebin entries referred to in the ML post seem to have been cleaned up...

Hi, unfortunately I was unable to verify this bug existed for me as it uses X509 certificates. It was confirmed as a bug by the developers and was confirmed as resolved by Frymaster.

I tested the fix posted on 2008-09-08 but I didn't test the proposed fix as the system went live (we manually installed the .deb from 8.10 which is a later version) - if this still needs checked I suppose I can set up a VM or similar

as regards to pastebin cleaning up entries - anyone know a good pastebin system I can download which doesn't erase entries with the expiry time set to "never"? :(

frymaster:
Could you describe how to reproduce the bug from a basic hardy system (what packages should be installed, what configuration files should be used...) so that someone else with minimal knowledge can reproduce the bug and verify it is fixed. You can pastebin configfiles to pastebin.ubuntu.com, that's easier than installing your own :)
Thanks

OK, I've spent a fair amount of time trying to reproduce that issue with 2.1~rc7-1ubuntu3.3.
CCD are working great. tls-remote is working great.

I've a setup with

tls-remote client
client-config-dir ccd
and a ccd/client script that pushes a specific route

Connecting with a certificate with CN=client works and pulls the right route from ccd/client.
So I just can't reproduce the bug, and without more help from the reporter I would abandon that SRU.

Hi Thierry:

http://sourceforge.net/mailarchive/forum.php?thread_name=dac97fdc77ef4700eab65450a4fc2451%40127001.org&forum_name=openvpn-users

That's the mail thread where the problem was discussed; sorry our pastebin stuff disappeared but it turns out the pastebin variety we use had a bug where it would treat permanent entries as one-month entries, so all our configs disappeared.

I can't post easy repro instructions because getting an x509 infrastructure working isn't easy :) I don't and didn't have time to set up a fresh VM and try to reproduce from scratch because i've never used one of those certificate wizards.

Surely if you are going to package a version of a program that is unstable source-wise, the package should be updated regularly to reflect this?

On a side note, I feel the barrier to reporting a bug is very high; I very greatly resent having to create an account just to report a bug (a bug which doesn't affect me since I had to switch to a manually maintained version anyway; reporting was just a courtesy to the community); the implication that I should then waste valuable time compiling repro details for a bug which the developers of the software have confirmed (and have confirmed a fix for) seems wrong to me.

My main concern is to get feedback about regressions. Upstream certainly knows what they are doing, and the patch might fix the bug, but it is important to get feedback from other users whether their system still works (misbuild, using different toolchain version than last build of the package, etc.).

Setting as WontFix in Hardy to allow reversion and publication of hardy SRU for bug 271777.

I am reopening this bug.
An openvpn client running rc7-1ubuntu3.5 fails to connect to the server with the following error:

Wed Sep 16 11:04:58 2009 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Wed Sep 16 11:04:58 2009 TLS Error: TLS object -> incoming plaintext read error
Wed Sep 16 11:04:58 2009 TLS Error: TLS handshake failed
Wed Sep 16 11:04:58 2009 SIGUSR1[soft,tls-error] received, process restarting

the debdiff provided in this bug report fixed indeed the problem

Thierry I can provide you a test vpn account so you can reproduce this bug ( the problem is in tls-auth option, without this option the connection works )

Reopening hardy task instead, since it is fixed in karmic.

I'm on Hardy and I'm using openvpn 2.1~rc7-1ubuntu3.5 as a server to which connect 3 or more different openvpn clients (from Windows, Debian, and Ubuntu).
I would like to help testing it from proposed, but I don't really see a clear test case, how to reproduce and how to verify if the package from -proposed works or not.

I'm also using ccd to push stuff to clients and also using tls-auth. The ceritifcates were generated with the scripts in easy-rsa (./build-key <client_name> , etc.)

Client versions that connect to this server are:

2.1.0-3ubuntu1 - from Ubuntu 10.10
2.1.3-2 - from Debian unstable
2.1.3 - from Windows 7

there isn't a clear step-by-step set of repro instructions (I couldn't create one because I was using my own x509 infrastructure and I've never used easy_rsa in my life) but basically, if you're using x509 certificates (ie the same kind you could install in your web browser, for example), and it picks up the name of your client (ie ccd works), then the bug is fixed. The bug _ONLY_ affected x509 certificates; other ways openvpn had of identifying clients were never affected.

As far as I can tell, there was a rc7~1ubuntu3.3 version which was buggy so 3.4 was put in -proposed I guess with the fix. That fix was later taken out in rc7~1ubuntu3.5 in favor of something else.

I'm running rc7~1ubuntu3.5 for a year now on my Hardy, with x509 certificates and ccd and I did not have any problems with it.

Soo... I did some more digging and I think I've found the thing. The problem occurs ONLY when the CN appears first in the certificate's subject, like this:

write(1, "Fri Dec 3 15:08:12 2010 us=921796 89.136.48.193:48274 VERIFY OK: depth=0, /<email address hidden>\n", 147) = 147

Notice the CN=ximi3 is the first and the result is:

open("ccd/UNDEF", O_RDONLY) = -1 ENOENT (No such file or directory)

If the CN is not the first, everything is alright:

write(1, "Fri Dec 3 15:09:13 2010 us=139668 89.136.48.193:40757 VERIFY OK: depth=0, /<email address hidden>\n", 147) = 147
write(1, "Fri Dec 3 15:09:13 2010 us=276204 89.136.48.193:40757 [ximi2] Peer Connection Initiated with 89.136.48.193:40757\n", 114) = 114
open("ccd/ximi2", O_RDONLY) = 6

The problem is hard to find because when you generate the certificates with the included easy-rsa scripts, the order of the fields in the generated certificate is:

root@ds9:/etc/openvpn/easy-rsa# cat /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf | grep -A8 '\[ policy_anything \]'
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

What I did was I moved the CN to the beginning:

root@ds9:/etc/openvpn/easy-rsa# cat openssl.cnf | grep -A8 '\[ policy_anything \]'
[ policy_anything ]
commonName = supplied <----
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
emailAddress = optional

So now my generated certificate had the CN at the front. I'm guessing the bugreporters used some other tools to generate their certificates which put the CN at the front. As was in this example on the mailing list, if you look at the strace output of Jonathan:

http://sourceforge.net/mailarchive/message.php?msg_name=dac97fdc77ef4700eab65450a4fc2451%40127001.org

write(1, "Thu Sep 4 23:49:13 2008 us=5872"..., 189Thu Sep 4 23:49:13 2008
us=587265 87.127.168.35:55835 VERIFY OK: depth=0,
/CN=lifeless-jupiter/ST=ED/C=UK
/emailAddress=admin@127001.org/O=localhost/OU=localhost_OpenVPN_client_certificate
) = 189

There you have the repro for it, just modify the Ubuntu-included openssl.cnf and generate a certificate in which the CN is first.

I can confirm this bug in 2.1~rc7-1ubuntu3.5 on Hardy.
Please re-add the fix and get it in -proposed, I'll be happy to test it.

Extracted the fix from the old rc7-1ubuntu3.4 package from hardy-proposed (which never got in the -updates), and applied it to the current package (rc7-1ubuntu3.5). See attached debdiff. Hope it helps.

Subscribing ubuntu-sponsors.

uploaded openvpn 2.1~rc7-1ubuntu3.6 to hardy-proposed

I don't see it in -proposed yet, when should it appear?

In hours or days. It needs to get manually accepted. Once it in -proposed, you will get notified.

Accepted openvpn into hardy-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Tested the package from -proposed with the same certificate I generated in comment #25 and this time is seems to work just fine:

root@ds9:~# apt-cache policy openvpn
openvpn:
  Installed: 2.1~rc7-1ubuntu3.6
  Candidate: 2.1~rc7-1ubuntu3.6
  Version table:
 *** 2.1~rc7-1ubuntu3.6 0
        500 http://archive.ubuntu.com hardy-proposed/main Packages
        100 /var/lib/dpkg/status
     2.1~rc7-1ubuntu3.5 0
        500 http://ftp.astral.ro hardy-updates/main Packages
     2.1~rc7-1ubuntu3.3 0
        500 http://security.ubuntu.com hardy-security/main Packages
     2.1~rc7-1ubuntu3 0
        990 http://ftp.astral.ro hardy/main Packages

root@ds9:/etc/openvpn# strace -s256 openvpn --config /etc/openvpn/server.conf > /tmp/strace-good.txt 2>&1

root@ds9:~# cat /tmp/strace-good.txt |grep ximi3
recvfrom(4, " \377d\333ii\266\31ow\24\5I\266\362\267\211!M\341\224\373\226\346$\0224/\325\0\0\0&M\10\324m\0\0\0\0\4\3U\4\3\23\5ximi31\v0\t\6\3U\4\6\23\2RO1\v0\t\6\3U\4\10\23\2CJ1\0240\22\6\3U\4\7\23\vCluj Napoca1\f0\n\6\3U\4\n\23\3DS91 0\36\6\t*\206H\206\367\r\1\t\1\26\21gimre@nara", 1558, 0, {sa_family=AF_INET, sin_port=htons(60504), sin_addr=inet_addr("89.136.48.193")}, [16]) = 142
write(1, "Wed Dec 15 16:45:02 2010 us=209343 89.136.48.193:60504 VERIFY OK: depth=0, /<email address hidden>\n", 147) = 147
write(1, "Wed Dec 15 16:45:02 2010 us=369512 89.136.48.193:60504 [ximi3] Peer Connection Initiated with 89.136.48.193:60504\n", 114) = 114
open("ccd/ximi3", O_RDONLY) = 6
write(1, "Wed Dec 15 16:45:02 2010 us=370180 ximi3/89.136.48.193:60504 OPTIONS IMPORT: reading client specific options from: ccd/ximi3\n", 125) = 125

My old certificates do work also, it seems the fix didn't break anything.

This bug was fixed in the package openvpn - 2.1~rc7-1ubuntu3.6

---------------
openvpn (2.1~rc7-1ubuntu3.6) hardy-proposed; urgency=low

  * ssl.c: re-applied fix from upstream to fix extract_x509_field_ssl
    where the extraction would fail on the first field of the subject
    name (LP: #265058)
 -- Imre Gergely <email address hidden> Tue, 14 Dec 2010 17:56:23 +0100