[Pkg-openldap-devel] Bug#462588: Bug#462588: Fails to start slapd ldaps:/// on upgrade

[Steve Langasek]

On Mon, Feb 04, 2008 at 10:03:27AM +0100, Niccolo Rigacci wrote:
> > > However this is strange beacuse LDAP.CONF(5) states that 
> > > TLS_REQCERT "allow" means:

> > >   The server certificate is requested. If no certificate is 
> > >   provided, the session proceeds normally. If a bad certificate 
> > >   is provided, it will be ignored and the session proceeds normally.

> > What client are you using?  If you use ldapsearch -ZZ, for instance, this
> > overrides the TLS_REQCERT value in /etc/ldap/ldap.conf.

> On the client (which is not the slapd server) I use the following 
> command line:

> ldapsearch -x -H ldaps://cheope.mydomain.org/ \
>     -x -D "cn=admin,dc=mydomain,dc=org" -W \
>     -b "dc=mydomain,dc=org"

> Doing it with the alias server name and "TLS_REQCERT allow" 
> results into the error:

> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

> On the server the log reports:

> slapd[29352]: conn=25 fd=16 ACCEPT from IP=192.168.200.244:37323 (IP=0.0.0.0:636)
> slapd[29352]: conn=25 fd=16 TLS established tls_ssf=32 ssf=32
> slapd[29352]: conn=25 fd=16 closed (connection lost)

> I need "TLS_REQCERT never" on the client to succeed.

> ldapsearch is version 2.4.7-3, slapd is version 2.4.7-3, no 
> TLSVerifyClient option is set in slapd.conf.

Ok, I can reproduce this problem.  There are two remaining issues here, that
I can see:

- the behavior of "TLS_REQCERT allow" appears to be equivalent to
  "TLS_REQCERT try" in its handling of wrong certificates
- with GnuTLS, subjectAltName values are not being validated properly

I'll have a look at both of these issues.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org