NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: lib/53675: ldaps appears to be broken



The following reply was made to PR lib/53675; it has been noted by GNATS.

From: Brad Spencer <brad%anduin.eldar.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: lib/53675: ldaps appears to be broken
Date: Tue, 06 Aug 2019 12:21:10 -0400

 coypu%sdf.org@localhost writes:
 
 > The following reply was made to PR lib/53675; it has been noted by GNATS.
 >
 > From: coypu%sdf.org@localhost
 > To: gnats-bugs%netbsd.org@localhost
 > Cc: 
 > Subject: Re: lib/53675: ldaps appears to be broken
 > Date: Tue, 6 Aug 2019 07:25:22 +0000
 >
 >  I recommend reporting this problem upstream.
 >  - Is the problem to do with too new OpenSSL, or to do with netbsd
 >    changes?
 >  
 >  Comparing to another OS that uses the same major version OpenSSL will be
 >  good (e.g. some of the up to date linuxes)
 >  
 
 
 I do not think that this is a upstream problem.
 
 
 I have set up a OpenLDAP server on the following system types compiled
 from pkgsrc 2018Q4:
 
 NetBSD - 8.0_STABLE
 OpenSSL 1.0.2k  26 Jan 2017
 ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.23 $
         (LDAP library: OpenLDAP 20439)
 
 NetBSD - 9.0_BETA (upgraded system from 8.0_STABLE)
 OpenSSL 1.1.1c  28 May 2019
 ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.23 $
         (LDAP library: OpenLDAP 20439)
 (from the installed 8.0_STABLE 2018Q4 pkgsrc packages)
 ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.47 (Feb 13 2019 05:07:27) $
         brad%gimli.nat.eldar.org@localhost:/lhome/WORK/databases/openldap-client/work/openldap-2.4.47/clients/tools
         (LDAP library: OpenLDAP 20447)
 
 
 A 389DS system was set up and configured on this system:
 
 CentOS 7.6.1810 - 3.10.0-957.27.2.el7.x86_64
 OpenSSL 1.0.2k-fips  26 Jan 2017
 openldap-clients.x86_64                 2.4.44-21.el7_6                @updates 
 
 
 In addition to testing from all of the above systems, I tested the
 ldapsearch client from the following:
 
 ArchLinux - 5.2.6-arch1-1-ARCH
 OpenSSL 1.1.1c  28 May 2019
 openldap 2.4.47-3
 
 FreeBSD - 12.0-RELEASE
 OpenSSL 1.1.1a-freebsd  20 Nov 2018
 openldap-client-2.4.47
 
 NetBSD - 8.99.23
 OpenSSL 1.1.0h  27 Mar 2018
 ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.23 $
         (LDAP library: OpenLDAP 20439)
 
 
 
 In ALL cases a recent NetBSD-current (libcrypto.so.14) or NetBSD
 9.0_BETA will fail to perform an ldapsearch via TLS to either a OpenLDAP
 server or a 389DS server when using the base OS ldapsearch binary.  In
 all other cases, every other system of every other type works fine.  In
 addition the NetBSD 9.0_BETA system will work fine too if it uses
 ldapsearch from in installed pkgsrc that was present on the system.  In
 that case, /usr/pkg/bin/ldapsearch was from the 8.0_STABLE era and is
 compiled against libcrypto.so.12 which is still present on the system.
 To mess with ones mind even more, openssl s_client works just fine on
 9.0_BETA, it is just the base OS ldapsearch does not (and neither does
 pam_ldap or nss_ldap).
 
 I think that this ruled out everything but the situation where the base
 ldap client code is too old (but compiled anyway) for the openssl
 present in the base OS.
 
 What I am unable to try right now is a pkgsrc openldap-client (which may
 be a newer ldap client) compiled against 9.0_BETA or -current.  This
 would eliminate the ldap client code from the base OS, but would use the
 newer openssl.
 
 Further in all cases, proper certificates were obtained from Let's
 Encrypt and the needed CA anchors were put into place in the OSs as
 needed.  All system pass the openssl s_client test and validate the
 certificate chain (as is required by OpenLDAP client code) without any
 special flags to openssl s_client.
 
 
 
 
 
 
 -- 
 Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org
 


Home | Main Index | Thread Index | Old Index