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

Bug #265058 reported by frymaster on 2008-09-05
18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openvpn (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
Unassigned
Intrepid
Undecided
Unassigned

Bug Description

Binary package hint: openvpn

In Ubuntu 8.04.1 the version of openvpn available is 2.1~rc7 which has a pretty serious bug:

From a reply to the openvpn mailing list after we were having problems:

"try upgrading to 2.1_rc9 ; in 2.1_rc7 the code to extract a common name from a certificate DN was broken. v2.1_rc8 and higher reverted back to the old mechanism, as found in 2.0.9."

This means any attempt to use the ccd feature (different options for different clients based on the name of the client certificate) will fail. Our setup involved an inter-LAN vpn; we could not push the appropriate routes as it couldn't identify the clients properly

Manually upgraded to rc9 and our setup now works

Stefan Lesicnik (stefanlsd) wrote :

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

frymaster (frymaster-127001) wrote :

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.

Stefan Lesicnik (stefanlsd) wrote :

Suggesting this for a backport into Hardy.

Changed in openvpn:
status: New → Confirmed
Stefan Lesicnik (stefanlsd) wrote :

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

Stefan Lesicnik (stefanlsd) wrote :

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

frymaster (frymaster-127001) wrote :

Hi,

This resolves the issue and CNs are picked up.

Thanks

Stefan Lesicnik (stefanlsd) wrote :

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

Chuck Short (zulcss) wrote :

Already fixed for intrepid.

Changed in openvpn:
status: New → Fix Released
status: Fix Released → Confirmed
status: Confirmed → Fix Released
Chuck Short (zulcss) wrote :

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

Martin Pitt (pitti) wrote :

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!

Changed in openvpn:
status: Confirmed → Fix Committed
Martin Pitt (pitti) wrote :

Any testers on this one?

Thierry Carrez (ttx) wrote :

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...

Stefan Lesicnik (stefanlsd) wrote :

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.

frymaster (frymaster-127001) wrote :

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"? :(

Thierry Carrez (ttx) wrote :

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

Thierry Carrez (ttx) wrote :

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.

frymaster (frymaster-127001) wrote :

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.

Martin Pitt (pitti) wrote :

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.).

Thierry Carrez (ttx) wrote :

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

Changed in openvpn (Ubuntu Hardy):
status: Fix Committed → Won't Fix

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 )

Changed in openvpn (Ubuntu):
status: Fix Released → New
Martin Pitt (pitti) wrote :

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

Changed in openvpn (Ubuntu):
status: New → Fix Released
Changed in openvpn (Ubuntu Hardy):
status: Won't Fix → Triaged
Imre Gergely (cemc) wrote :

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

frymaster (frymaster-127001) wrote :

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.

Imre Gergely (cemc) wrote :

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.

Imre Gergely (cemc) wrote :

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.

Imre Gergely (cemc) wrote :

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.

Martin Pitt (pitti) wrote :

Subscribing ubuntu-sponsors.

Benjamin Drung (bdrung) wrote :

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

Imre Gergely (cemc) wrote :

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

Benjamin Drung (bdrung) wrote :

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!

Changed in openvpn (Ubuntu Hardy):
status: Triaged → Fix Committed
Imre Gergely (cemc) wrote :

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.

Martin Pitt (pitti) on 2010-12-15
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

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

Changed in openvpn (Ubuntu Hardy):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments