Red Hat Bugzilla – Bug 800787
TLS connection to AD no longer works
Last modified: 2013-03-03 20:29:59 EST
Description of problem: My Python AD searches stopped working when I updated openldap from openldap-2.4.26-5.fc16.x86_64 to openldap-2.4.26-6.fc16.x86_64. Now, it always returns this error: ldap.CONNECT_ERROR: {'info': "TLS error -8179:Peer's Certificate issuer is not recognized.", 'desc': 'Connect error'} When I downgraded back to openldap-2.4.26-5.fc16.x86_64, the TLS connection worked OK again. Version-Release number of selected component (if applicable): openldap-2.4.26-6.fc16.x86_64 How reproducible: I used this test script using python-ldap wrapper: # cat /tmp/testtls.sh import ldap ad_conn = ldap.initialize('ldap://dhcp201-112.englab.pnq.redhat.com') ad_conn.set_option(ldap.OPT_DEBUG_LEVEL, 255) ad_conn.set_option(ldap.OPT_X_TLS_NEWCTX, 0) ad_conn.set_option(ldap.OPT_X_TLS_CACERTFILE, '/home/mkosek/WinCert2.cer') ad_conn.start_tls_s() # python /tmp/testtls.sh Traceback (most recent call last): File "/tmp/testtls.sh", line 6, in <module> ad_conn.start_tls_s() File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 526, in start_tls_s return self._ldap_call(self._l.start_tls_s) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) ldap.CONNECT_ERROR: {'info': "TLS error -8179:Peer's Certificate issuer is not recognized.", 'desc': 'Connect error'} Steps to Reproduce: 1. Prepare an LDAP server with support of TLS connection, prepare its certificate (I used Active Directory server) 2. Prepare the script below which will test the TLS connection with provided certificate and server address 3. Run the script Actual results: TLS connection failed with the TLS error above Expected results: TLS connection succeeds, no error is returned
The way openldap TLS initialization works in openldap-2.4.26-6 and later is this: When you have an LDAP *ld or an ldap handle created by ldap.initialize, and you call ldap_set_option to set options in this handle, they are stored in the options area of the handle, but not in the TLS options area of the handle, until you call set_option(ldap.OPT_X_TLS_NEWCTX, 0). This causes the creation of the new TLS context and writes the saved TLS option settings into the new TLS context. If you then attempt to set another TLS option in the same ldap handle, the changes will again be stored in the ldap option area, but not in the TLS context.
Thanks for explanation Rich. When I changed the order of operations in our TLS initialization procedure this way: ad_conn = ldap.initialize('ldap://dhcp201-112.englab.pnq.redhat.com') ad_conn.set_option(ldap.OPT_X_TLS_CACERTFILE, '/home/mkosek/WinCert2.cer') ad_conn.set_option(ldap.OPT_X_TLS_NEWCTX, 0) ad_conn.start_tls_s() it worked. Therefore I think we can close this bug as NOTABUG.