Full_Name: Martin O'Neal Version: openldap-2.4.31 OS: ubuntu wily URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.68.2.190) The handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with a self-signed certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK try Error: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK try OK
dog@pavlov.com wrote: > Full_Name: Martin O'Neal > Version: openldap-2.4.31 Note that 2.4.31 is almost for years old. Hence the standard question: Can you reproduce this with current release 2.4.44? Ciao, Michael.
--On Friday, February 19, 2016 4:02 PM +0000 dog@pavlov.com wrote: > Full_Name: Martin O'Neal > Version: openldap-2.4.31 As already noted by Michael, that is an ancient release. In addition, since you're using a build provided by Debian/Ubuntu, it links to GnuTLS which has its own numerous issues. I'd strongly advise you: (a) Use a current OpenLDAP release (b) Use an OpenLDAP release that is linked to OpenSSL rather than GnuTLS If after both of those conditions are true you can still reproduce a problem, please follow up. If building OpenLDAP software is not in your line of expertise, you may wish to examine the options from the LTB project or Symas. <http://ltb-project.org/wiki/download#openldap> <https://symas.com/products/openldap-directory/> --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
Hi, The box was running Ubuntu vivid so bumped to wily, which took openldap to 2.4.41, and the results are identical. If I get time I'll run up a test platform and install from source, then drop you a line with the results. Martin...
--On Saturday, February 20, 2016 6:06 PM +0000 dog@pavlov.com wrote: > > Hi, > > The box was running Ubuntu vivid so bumped to wily, which took openldap > to 2.4.41, and the results are identical. > > If I get time I'll run up a test platform and install from source, then > drop you a line with the results. Again, you could just install the builds from the LTB project. In any case, all options work fine for me with a self-signed cert with ldaps:/// URIs. (2.4.44, linked to OpenSSL). --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
dog@pavlov.com wrote: > Hi, > > The box was running Ubuntu vivid so bumped to wily, which took openldap to 2.4.41, and the results are identical. > > If I get time I'll run up a test platform and install from source, then drop you a line with the results. What commands are you testing with? Are you using STARTTLS as a critical extension? If not, failures will be ignored. Note that this is already documented. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Hi, This is a piece of code that I'm working on, rather than any bundled commands. The code works just fine (has for months) however I noticed in unit testing the operations empirically that the LDAP_OPT_X_TLS_REQUIRE_CERT option was handled differently depending on whether the TLS was provided implicitly over an ldaps: URI, or explicitly on an ldap: URI with STARTTLS. The pseudo sequence of functions is as follows: ldap_initialize ldap_set_option (various) if uri != ldaps: then ldap_start_tls_s ldap_sasl_bind_s Martin...
Ok, retested with latest code built from source. I also reconfirmed using a publicly available openldap server, to make sure it isn't something stupid I am doing locally. So you can reproduce easily, the test pseudo code is: ldap_initialize (ldaps://ldap.andrew.cmu.edu) ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT (enumerate options) ldap_sasl_bind_s ldap_initialize (ldap://128.2.11.104) ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT (enumerate options) ldap_start_tls_s ldap_sasl_bind_s The results are: Server with valid certificate, all values of LDAP_OPT_X_TLS_REQUIRE_CERT for both ldaps and ldap+starttls connect. This is what I would expect. Server with invalid certificate (IP does not match the cert FQDN), only NEVER and ALLOW values of LDAP_OPT_X_TLS_REQUIRE_CERT succeed for ldaps (this is what I would expect) however all values of LDAP_OPT_X_TLS_REQUIRE_CERT for ldap+starttls succeed, which is not what I would expect: I think that the certificate check should fail the connection, as per the ldaps behaviour. Martin...
Oh, and one more observation, the result is intermittent. The starttls connection actually fails as it is supposed to, something like 1/100 attempts. Martin....
This seems to have been resolved at some point in the past in one of the updates: now functions as expected. Fine to close from my perspective.
Actually, ignore me this is still connecting when it should fail. Don't close. ;)
Needs confirmation, GnuTLS only?
changed notes
Created attachment 589 [details] test program I cannot reproduce this. I've written a test program following your pseudocode and run it on Debian jessie (openldap 2.4.40/gnutls 3.3.8), stretch (openldap 2.4.44/gnutls 3.5.8), and buster (openldap 2.4.47/gnutls 3.6.7). In every case, StartTLS is consistently behaving correctly for me, returning "Connect error" with debug logging of "hostname does not match common name in certificate". I'm attaching my test program. Compile with: gcc -std=c99 -o its8374 its8374.c -lldap I'm afraid this ticket requires a reliable test program or script in order to be actionable. Thanks.
Going to mark resolved/WFM for now. If you can provide a reliable program demonstrating the issue, follow up and it will be re-opened.
Test comment, please ignore
Hi Martin, Due to a bug, you were not receiving updates to this issue. Please review comment #13, we are in no way able to reproduce the problem you presented. If you can provide a working example of correct API usage that results in what you reported, please attach it here. Regards, Quanah
Hi, looks like it has been resolved at some point along the way: good to close. I found the bug in the same time frame as this one: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248 Although it persisted after the fix was back ported. I guess it has been cleaned up along the way. Regards, Martin O'Neal
(In reply to dog@pavlov.com from comment #17) > Hi, looks like it has been resolved at some point along the way: good to > close. > > I found the bug in the same time frame as this one: > https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248 > > Although it persisted after the fix was back ported. > > I guess it has been cleaned up along the way. > > Regards, > Martin O'Neal Great, thank you for the confirmation!