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: 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.