[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RedHat 9's ldapsearch segfaults with SubjectAltName certificates
Ok,
Maybe I'm just stupid, but with the impending upgrade of my production
servers from 2.0.27 to 2.1.22, I've have bitten the bullet and generated
SSL certificates for them that utilize the SubjectAltName construct.
This is required because the master uses a private network to send the
update traffic to the slave(s) so they have to be known by different
names.
However, another member of my team is building a cluster that is using
stock RedHat 9's openldap (2.0.27-8), nss_ldap (202-5), and nscd
(2.3.2-27.9) and through the process of elimination we have discovered
that the ldapsearch binary will segfault if the LDAP server's SSL
certificate contains the SubjectAltName parameters.
I attempted to upgrade one of the systems to OpenLDAP 2.1.22, but then
nscd refused to run and I had to reimage the system because there was no
way in..... Ouch!
By running ldapsearch with -d -1 flags, I see the following:
TLS trace: SSL_connect:SSLv3 flush data
tls_read: want=5, got=5
0000: 14 03 01 00 01 .....
tls_read: want=1, got=1
0000: 01 .
tls_read: want=5, got=5
0000: 16 03 01 00 30 ....0
tls_read: want=48, got=48
0000: f5 15 2e 32 c1 bb 67 5f 86 30 87 ea 1f fc 87 82 ...2..g_.0......
0010: f1 e4 8c ca 0b e8 07 24 1b f4 28 b6 d1 4d fe b8 .......$..(..M..
0020: 5e ba 45 95 bd 40 09 0f db 87 02 fe ea 4c 3d 54 ^.E..@.......L=T
TLS trace: SSL_connect:SSLv3 read finished A
Segmentation fault
When we use a certificate that doesn't have subjectAltName in it, the
next thing printed out by ldapsearch -d -1 is "ldap_bind_s" instead of
"Segmentation fault".
This segfault happens with -Z as well as -ZZ, but not when -Z is not
used. Therefore, it is obviously in the TLS processing somewhere.
Anyone seen this? Anyone have a recommendation of how to fix this
(would SUSE be better?)?
Thanks,
--
Frank Swasey | http://www.uvm.edu/~fcs
Systems Programmer | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
=== God Bless Us All ===