Bug 171814 - OpenLDAP 2.2 client with TLS can't access 2.0 server
OpenLDAP 2.2 client with TLS can't access 2.0 server
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: openldap (Show other bugs)
4.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Safranek
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-26 15:14 EDT by Jim Klossner
Modified: 2015-01-07 19:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-21 04:33:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jim Klossner 2005-10-26 15:14:34 EDT
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:
Comment 1 Jay Fenlason 2005-10-26 22:31:10 EDT
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? 
Comment 2 Jay Fenlason 2005-10-26 23:17:12 EDT
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? 
Comment 4 Jan Safranek 2007-06-21 04:33:56 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.