Re: (ITS#3158) ldapsearch does not match simple hostnames against fqdns in certificates

[walst005@umn.edu]

Sorry to dig up an old, closed bug report, but this is affecting us as well.

Arne Brutschy wrote regarding OpenLDAP version 2.2.11:
> ldapsearch (and perhaps other ldap tools as well) has problems while verifying
> the servers tls certificates when connecting with a single hostname and the
> certificates cn is a fqdn.
>
> Example:
>
> ldapsearch -x -W -D "cn=manager,dc=example,dc=com" -H ldaps://ldap:636
>
> fails, but
>
> ldapsearch -x -W -D "cn=manager,dc=example,dc=com" -H
> ldaps://ldap.example.com:636
>
> succeeds when the CN in the certificate is "ldap.example.com". This is wrong.
> Openssls reference test client validates the certificate in the right way, you
> can test with:
>
> openssl s_client -connect ldap:636 -CApath /etc/ssl/certs

Kurt D. Zeilenga <Kurt@OpenLDAP.org>, replied:
> This behavior is by design.

I disagree with this default policy behavior decision.  The common name for
certificates does NOT have to match the FQDN of the host.  We're currently
trying to provide access to the LDAP server over two interfaces, one that's
public and one that's private.  The private interface IP address does not
resolve to the public host name, nor should it in our network setup.  The FQDN
requirement fails in this environment.

Because this default policy decision was hard-coded but provided no way forthe
administrator to override it, it's made the client unusable.  In order for us to
provide LDAP service on the internal and external interfaces, we will have to
run two LDAP servers and have one replicate the other.  This is a pretty extreme
work-around for something that should be a configurable client option.

-- 
Chad C. Walstrom <walst005@umn.edu>                   247 Gortner Hall
Asst. Director of IT                                Help: 612-625-9284
CBS Computing Services, UMN                        Phone: 612-624-2918

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB2tiriCU+4tVbo1sRAjKTAJ9KgABUJoqHqD6isOJg8OeWWR2BrwCeMfQY
9Ulg+y4uZk5pcNwHs96YxkE=oSpR
-----END PGP SIGNATURE-----