Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1175481 - MD5 certs prevent openvpn connection
MD5 certs prevent openvpn connection
Status: CLOSED DUPLICATE of bug 1174915
Product: Fedora
Classification: Fedora
Component: NetworkManager-openvpn (Show other bugs)
21
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-12-17 15:02 EST by Ilkka Tengvall
Modified: 2014-12-23 02:48 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-12-23 02:48:14 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ilkka Tengvall 2014-12-17 15:02:23 EST
Description of problem:

Openvpn in fedora is patched to disallow using of MD5 certs. For one to go around the patch, there is an environment variable to be set:  OPENSSL_ENABLE_MD5_VERIFY=1

https://bugzilla.redhat.com/show_bug.cgi?id=1160818


Version-Release number of selected component (if applicable):

NetworkManager-openvpn-gnome-0.9.9.0-3.git20140128.fc21.x86_64
NetworkManager-openvpn-0.9.9.0-3.git20140128.fc21.x86_64


How reproducible:

every time, if server uses MD5 certs.

Steps to Reproduce:
1. configure openvpn against host that uses MD5 certs
2. Modify systemd/system/NetworkManager.service to have the env variable
3. start tunnel

Actual results:
openvpn fails to verify certs

Expected results:
openvpn should verify the certs and work


Additional info:

If I do tunnel with "sudo OPENSSL_ENABLE_MD5_VERIFY=1 openvpn tunnel.ovpn" it works
If I do it with nmapplet, it won't.

I verified from process info, that nm-gui also sets the OPENSSL_ENABLE_MD5_VERIFY for both nm process and openvpn process. Tunnel still won't work.
Comment 1 Ilkka Tengvall 2014-12-18 08:45:43 EST
there is comment about secure_getenv possibly having effect on this:

https://bugzilla.redhat.com/show_bug.cgi?id=1157260#c17
Comment 2 David Mansfield 2014-12-18 09:01:02 EST
To clarify comment#1, myself and others have verified that the environment variable is being set properly (via /proc/<pid>/environ) however the workaround is not being activated.

Additionally, forcing the workaround by patching openssl DOES work.

Also, the same workaround works for other applications or when launching openvpn standalone.

So secure_getenv must be not returning anything.  It returns NULL when (from the manpage):

       *  the process's effective user ID did not match its real  user  ID  or
          the  process's  effective  group  ID did not match its real group ID
          (typically this is the result of executing  a  set-user-ID  or  set-
          group-ID program);

       *  the effective capability bit was set on the executable file; or

       *  the process has a nonempty permitted capability set.


So one of these must be happening when run under NetworkManager (and not from command line usage). Anyone in NM camp know about these three possibilities?
Comment 3 Steve 2014-12-21 10:10:39 EST
+1. I ran into exactly the same issue and attempted exactly the same troubleshooting steps as Ilkka Tengvall.  
Our system engineers are promising to regenerate certificates with SHA256 - but I don't know when they will get around to do so.
Comment 4 David Mansfield 2014-12-22 14:02:09 EST
bug#1174915 is a duplicate but provides the correct fix and fuller analysis of the problem.

This should be marked dup of that and the NetworkManager / selinux policy team should address this issue please.
Comment 5 Ilkka Tengvall 2014-12-23 02:47:34 EST
Yes, we truly have lousy communications within the company, Jarkko and I are collegues :) If it works for Jarkko, it works for me. We can close this ticket.
Comment 6 Ilkka Tengvall 2014-12-23 02:48:14 EST

*** This bug has been marked as a duplicate of bug 1174915 ***

Note You need to log in before you can comment on or make changes to this bug.