(ITS#6838) TLS client will not accept certificate for 'localhost'

[andrew.findlay@skills-1st.co.uk]

Full_Name: Andrew Findlay
Version: 2.4.24
OS: OpenSuSE 11.3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (88.97.25.132)


For various test and teaching purposes I have a set of OpenLDAP configs that run
small servers intended for local access only. As I run these on a wide variety
of machines and also give them to students to run on their own machines, all the
LDAP clients are set up to access the servers via the loopback interface:
typically ldap://localhost:1389/

Some of the configs use TLS. I have a local CA which issues simple server certs,
usually with 'CN=localhost' as part of the subject name. Since upgrading the OS
and OpenLDAP version of my main test environment I find that TLS connections are
failing:

> ldapsearch -d 768 -x -ZZ -H ldap://localhost:1389/ -b dc=example,dc=org
sn=trott
TLS: hostname (slab.skills-1st.co.uk) does not match common name in certificate
(localhost).
ldap_start_tls: Connect error (-11)
        additional info: TLS: hostname does not match CN in peer certificate

slab.skills-1st.co.uk is indeed the name of the machine, but I asked to connect
to 'localhost' so that is the name that should be checked against the
certificate.
If I put in any other alias for localhost in /etc/hosts and issue a certificate
for that, the connection is OK so the problem is specific to the string
'localhost', not to the use of the loopback interface in general.

I think the problem is in tlso_session_chkhost() in tls_o.c:

        if( ldap_int_hostname &&
                ( !name_in || !strcasecmp( name_in, "localhost" ) ) )
        {
                name = ldap_int_hostname;
        } else {
                name = name_in;
        }

If I understand this correctly, the intention appears to be to allow a
certificate issued for the FQDN of the machine to be accepted when it is
presented on the loopback interface. This may be a reasonable thing to do, but
the current implementation prevents the use of a certificate issued specifically
for 'localhost'.

My client scripts used to work: I think this was purely because earlier versions
of the TLS client code were less careful about checking certificates.
Specifically, the 'self signed certificate in certificate chain' error was not
even reported unless client-side debugging was turned on.