From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: This bug started out with attempting to get an ES 4 update 2 box to authenticate using nss_ldap against a ES 3 update 4 box running openldap-servers-2.0.27-20. I am attempting to access on port 636 with TLS. I have several other ES 3 boxes accessing this server with nss_ldap and TLS successfully for user accounts. I believe that the root of this problem is related to the Open LDAP 2.2 client trying to access the Open LDAP 2.0 server using TLS. I attempted an ldapsearch with the 2.2 client, specifying -ZZ: [root@barg cacerts]# ldapsearch -h 10.17.1.253 -D "uid=root,dc=current,dc=net" -x -W -b dc=current,dc=net -p 636 -d 9 -ZZ '(uid=jkk)' ldap_create ldap_url_parse_ext(ldap://10.17.1.253:636) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection ldap_int_open_connection ldap_connect_to_host: TCP 10.17.1.253:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.17.1.253:636 ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_ndelay_on: 3 ldap_is_sock_ready: 3 ldap_ndelay_off: 3 ldap_open_defconn: successful ldap_send_server_request ber_flush: 31 bytes to sd 3 ldap_result msgid 1 ldap_chkResponseList for msgid=1, all=1 ldap_chkResponseList returns NULL wait4msg (infinite timeout), msgid 1 wait4msg continue, msgid 1, all 1 ** Connections: * host: 10.17.1.253 port: 636 (default) refcnt: 2 status: Connected last used: Wed Oct 26 15:11:10 2005 ** Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ** Response Queue: Empty ldap_chkResponseList for msgid=1, all=1 ldap_chkResponseList returns NULL ldap_int_select read1msg: msgid 1, all 1 ber_get_next ber_get_next failed. ldap_perror ldap_start_tls: Can't contact LDAP server (-1) On the 2.0 server: Oct 26 15:08:03 ns1 slapd[32614]: daemon: conn=63 fd=26 connection from IP=10.17.1.93:33040 (IP=0.0.0.0:636) accepted. Oct 26 15:08:03 ns1 slapd[32614]: conn=-1 fd=26 closed The connection is instantly opened and closed. Ethereal confirms this behaivor. However, if I turn off TLS everything works fine. I coped over the PEM-encoded version of the ca cert from the server onto the 2.2 client and put it in the /etc/openldap/cacerts directory as well. Version-Release number of selected component (if applicable): openldap-clients-2.2.13-4 How reproducible: Always Steps to Reproduce: 1. Set up an ES 3 server with Open LDAP 2.0.27-20 and configure TLS 2. Set up an ES 4 client with Open LDAP 2.2.13-4 and configure TLS 3. Attempt a search Additional info:
Hmm. I wrote a test to try this, and it WORKSFORME. But I'm using TLS_CACERT rather than CACERTDIR. To use CACERTDIR, I have to name the certificate file something wierd for openssl to find it. What happen if you try using CACERT instead of CACERTDIR?
The "something wierd" is the X509_NAME_hash of the X509_NAME of the cert AFAICT (with a .0 stuck on the end). I can't say I really understand OpenSSL internals, but it looks like if the certificate file is named anything else, OpenSSL adds the certificate to its data structures, but then can't find it later when it attempts to reopen the certificate file later. Is your certificate file properly named?
Closing this bug as it was in NEEDINFO for very long time wihtout response from reporter. If you can still reproduce the bug with latest RHEL 4 update and using CACERT instead of CACERTDIR, please contact Red Hat support at http://redhat.com/support.