Fredrik, I've learned the hard way now that settings in .ldaprc and ldap.conf have precedence over what you set in your Python code via ldap.set_option() or LDAPObject.set_option(). Best thing is to use this code-line to completely switch off processing of .ldaprc and ldap.conf in libldap:
os.environ['LDAPNOINIT']='1' Ciao, Michael. Fredrik Melander wrote: >> Hmm, there's nothing you can do at the python-ldap level. AFAIK cert >> validation is completely done within the OpenSSL libs, except the host name >> checking. >> >> Could you please test with OpenLDAP's command-line tool ldapsearch. This is >> important: Please use the tool which uses the very same libldap also used for >> python-ldap. >> >> If ldapsearch fails this would be something to raise on the openldap-software >> mailing list together with information about your build of libldap and the >> SSL/TLS libs used. Note that libldap could be build with GnuTLS or today even >> with Mozilla's libnss. >> >> Ciao, Michael. >> > > > > Hi, Michael. > Thanks for your reply. I've been looking into this, trying stuff on > different machines and once again it's the frustrating issue of > different OpenLDAP versions. > You might not remember this but I posted a question to this list a > couple of mounths ago about the chase referrals flag which also turned > out to be treated differently depending on OpenLDAP version. > > One of my machines here has (let's call it A) the RPM > openldap2-client-2.3.37-20.8 installed. While as another one (B) has > openldap2-client-2.4.9-7.4 (libldap-2.3.so.0 and libldap-2.4.so.2 > respectively). > > Of course you're right that python-ldap has nothing to do with this, > since ldapsearch gives the same results: > > Computer A: > ldapsearch -x -h "host.domain.de" -b "o=myorg,dc=net" -ZZ > > ldap_start_tls: Connect error (-11) > additional info: error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > > Computer B: > ldapsearch -x -h "host.domain.de" -b "o=myorg,dc=net" -ZZ > > # extended LDIF > # > # LDAPv3 > # base <o=myorg,dc=net> with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > > I'm posting this in case somebody runs into similar issues and also in > the hope that somebody has a suggestion on how to solve this. I might > also need to point out that it isn't about these two computers only. > That would be trivial. The application is going to be distributed in a > fairly big organization and I can't possibly demand that everybody has > the same OpenLDAP version. > > The most frustrating thing is perhaps that it is the old version that > has the desired behaviour. I know this is a bit off topic, but surely > there must be a way to check this also in later versions? It'd be much > appreciated if anybody could point me in the right direction here. > > Best regards, > Fredrik ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Python-LDAP-dev mailing list Python-LDAP-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
