Bug 51352 - SSL/TLS query fails
Summary: SSL/TLS query fails
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: openldap
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact: Aaron Brown
: 97675 97676 (view as bug list)
Depends On:
Blocks: 97675 97676
TreeView+ depends on / blocked
Reported: 2001-08-09 19:03 UTC by David Wright
Modified: 2014-08-31 23:24 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2006-08-04 20:25:53 UTC

Attachments (Terms of Use)

Description David Wright 2001-08-09 19:03:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0b; Windows NT 5.1; .NET CLR 
1.0.2817; COM+ 1.0.2204; .NET CLR 1.0.2914)

Description of problem:
Unencrypted LDAP queries work file;
  # ldapsearch -x "<filter>"
  <search results>
but TLS
  # ldapsearch -x -ZZ "<filter>"
  ldap_start_tls: Success
and ssl
  # ldapsearch -x -H ldaps://<IP> "<filter>"
  ldap_bind: Can't contact LDAP server
querries just break off (without core dump).

How reproducible:

Additional info:

This problem does not occur for 2.0.7, either from rpm or compiled 
locally, so it's not my OpenLDAP server. It occurs for 2.0.11 wether I 
get it from the roswell rpm or compile locally. I have tried --without-
threads, --without-cyrus-sasl, and --with-ldbm-api=gdbm; none of these 
help. I have tried with both the 0.9.6 and 0.9.6b OpenSSL libraries.

An ssldump would seem to indicate that the problem is in OpenLDAP, not 
the openssl libraries. All the handshakes and key exchanges go off 
without a hitch, then the client just up and quits.

# ssldump -A -i eth0 port 389
Kernel filter, protocol ALL, raw packet socket
1 1  0.0169 (0.0169)  C>S SSLv2 compatible client hello
   Version 3.1
   cipher suites
1 2  0.0174 (0.0004)  S>CV3.1(74)  Handshake
         Version 3.1
         cipherSuite         TLS_RSA_WITH_3DES_EDE_CBC_SHA
         compressionMethod                   NULL
1 3  0.0176 (0.0001)  S>CV3.1(1026)  Handshake
1 4  0.0176 (0.0000)  S>CV3.1(4)  Handshake
1 5  0.0300 (0.0124)  C>SV3.1(134)  Handshake
1 6  0.0300 (0.0000)  C>SV3.1(1)  ChangeCipherSpec
1 7  0.0300 (0.0000)  C>SV3.1(40)  Handshake
1 8  0.0669 (0.0368)  S>CV3.1(1)  ChangeCipherSpec
1 9  0.0669 (0.0000)  S>CV3.1(40)  Handshake
1    0.0722 (0.0052)  C>S  TCP FIN
1 10 0.0726 (0.0003)  S>CV3.1(24)  Alert
1    0.0726 (0.0000)  S>C  TCP FIN

One more potentialy useful piece of information. The following warnings 
get issued during "make":

tls.c:533: warning: initialization from incompatible pointer type
tls.c:535: warning: initialization from incompatible pointer type
tls.c:537: warning: initialization from incompatible pointer type
tls.c:533: warning: initialization from incompatible pointer type
tls.c:535: warning: initialization from incompatible pointer type
tls.c:537: warning: initialization from incompatible pointer type
ldapsearch.o: In function `print_entry': /root/sandbox/openldap-
2.0.11/clients/tools/ldapsearch.c:1068: the use of `mktemp' is dangerous, 
better use `mkstemp'
edit.o: In function `load_editor': /root/sandbox/openldap-
2.0.11/clients/ud/edit.c:146: the use of `tmpnam' is dangerous, better 
use `mkstemp'

Comment 1 Glen Foster 2001-08-09 20:10:17 UTC
We (Red Hat) should really try to fix this before next release.

Comment 2 Nalin Dahyabhai 2001-08-10 05:40:53 UTC
This is almost certainly a mismatch between your host name and the common name
recorded in /usr/share/ssl/certs/slapd.pem, especially if slapd.pem was

To check if this is the case, run:
openssl x509 -in /usr/share/ssl/certs/slapd.pem -noout -text

If the "CN" attribute of the "Subject" is something other than the host name
you're using to connect to the server (even if the certificate contains
"foo.example.com", and you need only use "foo" to establish a connection without

The fix is to remove slapd.pem, generate a new certificate by running "make
slapd.pem", and to make certain that the ldap user or group can read the new
certificate file.

Since this will behavior is sure to break a large number of cases in a
hard-to-pinpoint way, I'll revert the automatic creation of certificates for
openldap-2.0.11-12 and later.

Comment 3 David Wright 2001-08-10 07:35:44 UTC
Nalin, you are a minor diety. Minor, not major, because authough you put me on
the track of this extremely obscure problem, you didn't quite nail it. :-) My
slapd's certificate was completely accurate -- it said
and that is true. Furthermore, that's the name
under which ldapsearch contacted it. But apparantly 2.0.11 contains new code
(relative to 2.0.7) that FIRST RESOLVES the server IP and THEN COMPARES it to
the asserted cn. So when I regenerated my slapd's certificate with
it all worked, even when I give ldapsearch the IP insead of the FQDN.
I find this behaviour on the part of OpenLDAP rather absurd. What would it do if
an IP resolved to more than one FQDN? Certainly terminiating without any error
message doesn't help. I don't know if you have any influence with OpenLDAP, but
please do chime in if you do -- I'll also send mail to the OpenLDAP list.

Comment 4 Gabriel Donnell 2003-06-19 08:24:01 UTC
*** Bug 97675 has been marked as a duplicate of this bug. ***

Comment 5 Gabriel Donnell 2003-06-19 08:37:43 UTC
*** Bug 97676 has been marked as a duplicate of this bug. ***

Comment 6 Bill Nottingham 2006-08-04 20:25:53 UTC
Red Hat Linux and Red Hat Powertools are currently no longer supported by Red
Hat, Inc. In an effort to clean up bugzilla, we are closing all bugs in MODIFIED
state for these products.

However, we do want to make sure that nothing important slips through the
cracks. If, in fact, these issues are not resolved in a current Fedora Core
Release (such as Fedora Core 5), please open a new issues stating so. Thanks.

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