Description of problem:
openldap client tools segfault while using TLS if x509 cert contains
`subjectAltName=DNS:hostname.com`. subjectAltNames are necessary to
use TLS for replication within a load-blanaced TLS secure LDAP
Version-Release number of selected component (if applicable):
use a cert with a subjectAltName= entry, and do an ldap search with
Steps to Reproduce:
1.create a cert with a subjectAltName=DNS:hostname entry
2.restart LDAP using that cert.
3.ldapsearch -x -H ldap://example.com -ZZ -s base
results from LDAP database
We're having the exact same problem. Is there a resolution?
We are also experiencing the same problem with RHEL 3. Here is debug
output from ldapsearch:
$ ldapsearch -h ldaphost -W -x -ZZ -d 1
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS trace: SSL_connect:SSLv3 read server certificate A
TLS trace: SSL_connect:SSLv3 read server certificate request A
TLS trace: SSL_connect:SSLv3 read server done A
TLS trace: SSL_connect:SSLv3 write client certificate A
TLS trace: SSL_connect:SSLv3 write client key exchange A
TLS trace: SSL_connect:SSLv3 write change cipher spec A
TLS trace: SSL_connect:SSLv3 write finished A
TLS trace: SSL_connect:SSLv3 flush data
TLS trace: SSL_connect:SSLv3 read finished A
Segmentation fault (core dumped)
It appears this may be related to bug #85728 (for RH 9), which
already contains extensive debugging info.
*** Bug 112275 has been marked as a duplicate of this bug. ***
Created attachment 97953 [details]
Patch to resolve problem
Patch to resolve LDAP + SSL + AltSubject Bug
I submitted a patch
Here is a stack trace. I had to build this by hande using ddd one
instruction at a time. The problem is that the offending code calls
a null pointer and corrupts the stack, so a simple 'bt' cannot be
Stack trace of /usr/bin/ldapsearch
tls.c line 844: method=X509V3_EXT_get(ex);
tls.c line 845: method->ext_free(alt); <kills the stack>
The structure member method->ext_free=0 before calling
I've confirmed the patch corrects the problem I was encountering.
Turns out this was an unexpected API change between OpenSSL 0.9.6 and
0.9.7, so it had to be conditionalized on that for the SRPM because we
use the same SRPM for both RHEL 2.1 and 3.0 (though this problem doesn't
affect RHEL 2.1 because the code as-shipped is right for the version of
OpenSSL included with RHEL 2.1).
That last hunk at the end reverts an upstream change which was labelled
as a bug fix, so for the moment at least I've dropped it. The rest
should show up in 2.0.27-13.
Please add in that 'last hunk at the end' that you for the moment
dropped. Both parts are absolutely necessary for us!
If the second half of the patch does not get applied, then there still
is a significant bug of using LDAP with TLS.
OpenLDAP fixed their code over a year ago (Oct 2002 if I remember).
The bug is like this: Even if the program specifically requests the
OpenLDAP libraries to turn off certificate checking, all the checks
are turned off except the hostname check. For some reason, they
forgot to make the logic right when they coded 2.0. At the time of
the patch, they told me they only can fix 2.1, so they only patched
2.1. We already have 550 servers at our client site in production
that have the patched version of OpenLDAP 2.0. Since OpenLDAP fixed
the bug I assumed that RedHat would also apply the patch in a
reasonable ammount of time.
Please see the following OpenLDAP ITS report for more details:
It would be really disappointing if RedHat was unable to patch
OpenLDAP with an OpenLDAP patch that went well over a year ago.
Please reconsider adding the second half of the patch since other
major vendors (Sun, HP, IBM, Suse) already ship with the correct
Looking at it again, I've become convinced you're right. Checking the
host name only makes sense if the certificate is also being
cryptographically verified, otherwise it just provides an illusion of
increased security. Revising.
There is an additional LDAP bug that needs to be addressed. Please
see the following OpenLDAP bug report for details:
openldap-2.0.27-14 appears to be set for u3.
Can you confirm that it will be included?
re: comments 11 & 12, what timeframe do you expect the fix to be
released, is it possible to get srpm for this or will it be included
in update 3 ?
Created attachment 102781 [details]
Patch related to OpenLDAP ext_free bug
Bug 128364, entered against FreeRadius for RHEL3, is actually due to
this issue. I found OpenLDAP bug 1924
and applied it to OpenLDAP 2.0.27-11, with appropriate line changes as
shown below, and was able to get FreeRadius working with LDAP & TLS. I
hope this patch will be applied to the next OpenLDAP update (u3?).
Patch is attached.
*** Bug 128364 has been marked as a duplicate of this bug. ***
Can I get confirmation from users that the 2.0.27-14 package is
resolving the issues you are seeing?
I've confirmed that 2.0.27-14 resolves my problem.
Closing out based on confirmation from original reporter.
I just tried 2.0.27-14 too, and do not face the issue I was seeing. So
that way the problem is fixed.
Just a comment, though. The library files on /usr/lib still show the
version number as 2.0.17. For example:
ls -l /usr/lib/libldap*so*
lrwxrwxrwx 1 root root 19 Aug 20 19:02
/usr/lib/libldap_r.so -> libldap_r.so.2.0.17
lrwxrwxrwx 1 root root 19 Aug 20 19:01
/usr/lib/libldap_r.so.2 -> libldap_r.so.2.0.17
-rwxr-xr-x 1 root root 183336 Aug 20 18:26
lrwxrwxrwx 1 root root 17 Aug 20 19:02
/usr/lib/libldap.so -> libldap.so.2.0.17
lrwxrwxrwx 1 root root 17 Aug 20 19:01
/usr/lib/libldap.so.2 -> libldap.so.2.0.17
-rwxr-xr-x 1 root root 172496 Aug 20 18:26
The version number of the shared library doesn't necessarily reflect
the version number of the software package to which it belongs. Such
a correlation is usually the exception rather than the rule because
the version number of the shared library is not intended for human
consumption. The shared library's version number should be changed
exclusively to mark changes in the binary interface provided by that
An errata has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
*** Bug 126973 has been marked as a duplicate of this bug. ***