Red Hat Bugzilla – Bug 51352
SSL/TLS query fails
Last modified: 2014-08-31 19:24:00 EDT
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: Always 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 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ... 1 2 0.0174 (0.0004) S>CV3.1(74) Handshake ServerHello Version 3.1 ... cipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL 1 3 0.0176 (0.0001) S>CV3.1(1026) Handshake Certificate[1016]= ... 1 4 0.0176 (0.0000) S>CV3.1(4) Handshake ServerHelloDone 1 5 0.0300 (0.0124) C>SV3.1(134) Handshake ClientKeyExchange EncryptedPreMasterSecret[128]= ... 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'
We (Red Hat) should really try to fix this before next release.
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 auto-generated. 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 TLS). 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.
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 cn=128.95.53.190 and that is true. Furthermore, that's the name ldaps://128.95.53.190 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 cn=merleau.rprc.washngton.edu 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.
*** Bug 97675 has been marked as a duplicate of this bug. ***
*** Bug 97676 has been marked as a duplicate of this bug. ***
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.