Project

General

Profile

Bug #1037

Openvpn broken when used with LDAPS backend

Added by Florent Daigniere over 8 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
OpenVPN
Target version:
Start date:
11/24/2010
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.0
Affected Architecture:

Description

The connection to LDAP fails if SSL is used

To get it to work, I had to add the following to /var/etc/openvpn/server1.php
putenv("LDAPTLS_CACERT=/var/etc/openvpn/server1.ca");
putenv("LDAPTLS_REQCERT=never");

Associated revisions

Revision e1b17c7a (diff)
Added by Ermal Luçi over 8 years ago

Ticket #1037. Add suggestion in the ticket for using the CA supplied to openvpn for authenticating to SSL LDAP.

Revision befad728 (diff)
Added by Ermal Luçi over 8 years ago

Ticket #1037. Move environment manipulation to the authentication script since escaping slashes is not so easz on dynamic built paths.

Revision 1bab0df1 (diff)
Added by Jim Pingle over 8 years ago

Add suggested fix from ticket #1037

History

#1 Updated by Chris Buechler over 8 years ago

  • Category set to OpenVPN

#2 Updated by Ermal Luçi over 8 years ago

  • Status changed from New to Feedback

Committed your suggestions to repo.
Thank you.

#3 Updated by Florent Daigniere over 8 years ago

There seems to be an escaping problem, with your patch server1.php contains

sed: 2: "s/\/\/<template>/$authm ...": bad flag in substitute command: 'v'

The following works for me:

$sed .= "putenv(\"LDAPTLS_CACERT=\/var\/etc\/openvpn\/{$mode_id}.ca\");\\\n";
$sed .= "putenv(\"LDAPTLS_REQCERT=hard\");\\\n";

I didn't manage to get the other replacement string escaped properly

#4 Updated by Ermal Luçi over 8 years ago

Try the latest snapshot and see if i got this right this time.

#5 Updated by Florent Daigniere over 8 years ago

Nope. Still broken.

You are missing a semi-column in befad72821f522bf2c23a883f72ade8af48b8533.

-$sed .= " \$modeid = \"{$mode_id}\"";
+$sed .= " \$modeid = \"{$mode_id}\";";

With that fixed, it works.

By the way, you might also want to change LDAPTLS_REQCERT from never to hard everywhere (force the certificate verification). I am filling in another bug for it.

#6 Updated by Florent Daigniere over 8 years ago

It's confirmed-working with 1bab0df1b7fd06ecb2818f69187214a70de238b9

The other bug I was referring to:
bug #1052: Certificate validation of the LDAPS servers is not enforced

Thanks :)

#7 Updated by Chris Buechler over 8 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF