[Date Prev][Date Next]
Re: TLS problems with OpenLDAP
On Mon, 3 Nov 2008, LÉVAI Dániel wrote:
> Philip Guenther wrote:
> > Due to differences in APIs, OpenLDAP uses different routines to
> > perform the "check hostname against certificate" test depending on
> > whether it's built against OpenSSL or GNUtls. It appears the routine
> > used with GNUtls refuses to match IP addresses against a CN subjects
> > component, thus explaining that weird message.
> > (In ldap_pvt_tls_check_hostname(), 'len1' is only non-zero if the
> > hostname doesn't look like an IPv6 or IPv4 address, while the subject
> > CN test needs 'len1' to be the same as the length of the CN value.)
> So, it bugged me, and I've compiled a 2.4.12-Release with OpenSSL
> support on the exact same machine, while keeping the Debian package
> (with GnuTLS) too. Guess what, it works like charm with the slapd(8)
> binary linked against OpenSSL...
> With the exact same cert/key pair, with the IP address as the CN, with
> OpenSSL there is no error.
> Above all, the strange thing, is with the clients; one of the client is
> a Debian system too, with ldapsearch linked against GnuTLS. The client's
> ldapsearch won't work (!!!) with the server which uses OpenSSL. This is
> what is happening:
> $ ldapsearch -d 1 -Wx '(objectclass=*)' -H ldaps://192.168.1.3
> If somebody is interested in the full strace(1) log, I'll provide it gladly :)
> Philip, I'd like to report this issue, but I'm not sure to which
> softwares's tracker? What is the hunch regarding this; is this a GnuTLS
> issue, or is this an OpenLDAP issue. Though, after reporting to upstream
> I should report this to Debian BTS (at least I think).
There are at least two distinct issues here.
The handling of CN=IP-address by OpenLDAP when using GNUtls is an issue in
OpenLDAP and should be filed as an ITS at www.openldap.org.
The hang when a client using GNUtls connects to a server using OpenSSL and
the failures when both client and server are using GNUtls should, IMO,
both be taken up with Debian. They're the ones who think GNUtls should be
used; they're the one who should be hearing when it doesn't work and
dealing with issues with it.