Bug 727511 - ldclt SSL search requests are failing with "illegal error number -1" error
Summary: ldclt SSL search requests are failing with "illegal error number -1" error
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Command Line Utilities
Version: 1.2.9
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks: 690318 389_1.2.9 726742
TreeView+ depends on / blocked
 
Reported: 2011-08-02 10:43 UTC by Sankar Ramalingam
Modified: 2015-12-10 18:40 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-10 18:40:17 UTC


Attachments (Terms of Use)
0001-Bug-727511-ldclt-SSL-search-requests-are-failing-wit.patch (39.82 KB, patch)
2011-08-03 18:18 UTC, Rich Megginson
nkinder: review+
Details | Diff

Description Sankar Ramalingam 2011-08-02 10:43:07 UTC
Description of problem: On RHEl6, the SSL ldclt(stress) tests are failing with "Illegal error number -1" error. LDCLT clients doesn't do any SSL initialization.


How reproducible: Consistently.


Steps to Reproduce:
1. Install 389-ds-base packages on RHEL6.
2. Create an instance and configure SSL.
3. Run ldapsearch using mozldap clients. Search returns entries.
/usr/lib64/mozldap/ldapsearch -Z -P /etc/dirsrv/slapd-weelie/cert8.db -p 1636 -h 10.65.201.68 -D "cn=Directory Manager" -w Secret123 -b "dc=testldclt,dc=com" objectclass=* 
4. Run the same search with ldclt to stress the server.
ldclt -Z /etc/dirsrv/slapd-weelie/cert8.db -e esearch -p 1636 -h 10.65.201.68 -D "cn=Directory Manager" -w Secret123 -b "dc=testldclt,dc=com" -f "cn=new*" -n 1 -N 10 -T 10 -I '-1' -I 32


Actual results: LDCLT SSL search fails with - "Illegal error number -1" error.

DS access logs shows - conn=14 op=-1 fd=66 closed - Peer does not recognize and trust the CA that issued your certificate.

Expected results: LDCLT should successfully recognize the certificate and complete the search.


Additional info: The same LDCLT search is passing with DS8.2 builds on RHEL5.

Rich's comment for the problem reported.
Looks like ldclt on RHEL6 is just plain broken - it doesn't do any SSL initialization 

For a workaround, try this: 

LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-weelie; ldclt -Z /etc/dirsrv/slapd-weelie/cert8.db -e esearch -p 1636 -h 10.65.201.68 -D "cn=Directory Manager" -w Secret123 -b "dc=testldclt,dc=com" -f "cn=new*" -n 1 -N 10 -T 10 -I '-1' -I 32

The work around doesn't seems to be working.

Comment 1 Rich Megginson 2011-08-03 18:18:10 UTC
Created attachment 516559 [details]
0001-Bug-727511-ldclt-SSL-search-requests-are-failing-wit.patch

Comment 2 Rich Megginson 2011-08-03 19:19:38 UTC
To ssh://git.fedorahosted.org/git/389/ds.git
   9ad83ba..aea218c  master -> master
commit aea218c41961502b1cbdfc4c082ed494db6a49a7
Author: Rich Megginson <rmeggins@redhat.com>
Date:   Wed Aug 3 12:04:52 2011 -0600
    Reviewed by: nkinder (Thanks!)
    Branch: master
    Fix Description: Make all code in ldclt use the same function for creating
    and binding to an LDAP*.  Add code to initialize TLS/SSL when using
openldap
.
    If using cert client auth, add code to authenticate to the token using the
    given password.
    Platforms tested: RHEL6 x86_64
    Flag Day: no
    Doc impact: no

Comment 5 Sankar Ramalingam 2011-08-25 10:22:11 UTC
I could still reproduce the problem after upgrading the existing instance to 389-ds-base latest.

rpm -qi 389-ds-base
Name        : 389-ds-base                  Relocations: (not relocatable)
Version     : 1.2.8.2                           Vendor: Red Hat, Inc.
Release     : 1.el6_1.9                     Build Date: Thu 11 Aug 2011 10:50:39 PM EDT
Install Date: Tue 16 Aug 2011 09:18:45 PM EDT      Build Host: x86-012.build.bos.redhat.com
Group       : System Environment/Daemons    Source RPM: 389-ds-base-1.2.8.2-1.el6_1.9.src.rpm


ldclt -Z /etc/dirsrv/slapd-weelie/cert8.db -e esearch -p 1636 -h 10.65.201.68 -D "cn=Directory Manager" -w Secret123 -b "dc=testldclt,dc=com" -f "cn=new" -n 1 -N 10 -T 10 -I '-1' -I 32 -W 1
ldclt version 4.23
ldclt[25826]: Starting at Thu Aug 25 12:34:30 2011

ldclt[25826]: T000: Cannot ldap_simple_bind_s (cn=Directory Manager, Secret123), error=-1 (Can't contact LDAP server)
ldclt[25826]: Illegal error number -1
ldclt[25826]: T000: Cannot ldap_simple_bind_s (cn=Directory Manager, Secret123), error=-1 (Can't contact LDAP server)



tail -f /var/log/dirsrv/slapd-weelie/access

[25/Aug/2011:12:33:53 -0400] conn=867 fd=69 slot=69 SSL connection from 10.65.201.68 to 10.65.201.68
[25/Aug/2011:12:33:53 -0400] conn=867 op=-1 fd=69 closed - Peer does not recognize and trust the CA that issued your certificate.
[25/Aug/2011:12:34:06 -0400] conn=868 fd=69 slot=69 SSL connection from 10.65.201.68 to 10.65.201.68
[25/Aug/2011:12:34:06 -0400] conn=868 op=-1 fd=69 closed - Peer does not recognize and trust the CA that issued your certificate.
[25/Aug/2011:12:34:31 -0400] conn=869 fd=69 slot=69 SSL connection from 10.65.201.68 to 10.65.201.68
[25/Aug/2011:12:34:31 -0400] conn=869 op=-1 fd=69 closed - Peer does not recognize and trust the CA that issued your certificate.

Comment 6 Rich Megginson 2011-08-25 13:25:43 UTC
Right.  This issue is not fixed for 6.1.z or DS9.0.  It will be fixed for 6.2.0/DSIPA2.1


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