python-ldap-dev

Expired server certificate

[Fredrik M. <mel...@df...>]

Hi Michael and the list,

sorry to bother you again, but since I think my last mail drowned in the
unusually high traffic that day, I'm posting my question again. I've
done some research since then I really can't figure this one out.

This relates to my previous question about server certificates. Simply
put: how do I get python-ldap to throw an exception when the server
certificate is expired?

I've given my LDAP server an expired cert for testing, but when calling
start_tls_s() the script just proceeds as were nothing wrong.

Wading through the source code and google results unfortunately didn't
get me any further either.

Thankful for any advice!

Cheers,
Fredrik

Re: Expired server certificate

[Michael S. <mi...@st...>]

Fredrik Melander wrote:
> I've given my LDAP server an expired cert for testing, but when calling
> start_tls_s() the script just proceeds as were nothing wrong.

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.

Re: Expired server certificate

[Fredrik M. <mel...@df...>]

> 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

Re: Expired server certificate

[Michael S. <mi...@st...>]

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

Re: Expired server certificate

[Fredrik M. <mel...@df...>]

Hey Michael,
thanks for remembering! I will it out!

Best,
Fredrik



Michael Ströder schrieb:
> 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
> 
>