[email protected] wrote: > Am Freitag 18 Februar 2011, 13:17:17 schrieb > [email protected]: >> On Fri, Feb 18, 2011 at 12:30:25AM +0000, [email protected] wrote: >>> Used to work - since when, what release, what else has changed since >>> then? >> >> Unfortunately I cannot tell you exactly when this changed. In any >> case, the change only affects a different bug which was masking the >> problem that I now see. >> >> I do know that 2.3.32 as shipped with SLES 10.3 masks the problem by >> not checking the server certificate properly. So does 2.4.12 as >> shipped with OpenSuSE 11.1. Both will allow ldapsearch -ZZ to connect >> to *any* TLS-capable server if they do *not* have access to the CA >> certificate. >> >> 2.4.24 built on OpenSuSE 11.3 (i.e. using OpenSSL 1.0) correctly >> refuses to connect if there is no CA cert. > Yes, older openSUSE releases used a bad (i.e. less secure) default for > the TLS_REQCERT setting. That's why you never ran into the problem before > :/
Sigh... Apparently nobody reads the part of the doc that says "there is no good reason to change this from the libldap default." >> All versions that I have tested (certainly back to 2.3.32) incorrectly >> fail to connect when the URL is ldap://localhost:1389/ and a CA cert >> is provided. > Yes, AFAIK libldap's behavior of trying to figure out the machines real > hostname when connecting to localhost and using that hostname to verify > the server's certificate is there since quite some time already. It will > only verify against "localhost" when it completely fails to get the > machines' real name. I always considered that a feature more than a bug. Agreed. Server certs are supposed to carry the host's FQDN. "localhost" is just a magic alias; in a cert it shouldn't be anywhere other than a subjectAltName. >>> I'll note that I just tested some localhost certs a few days ago and > they were >>> fine, and the cert verification code hasn't changed in quite a long > time. >>> >>> (E.g., ITS#6711 the test setup there uses localhost with no problem.) > But if I see it correctly it sets "TLSVerifyClient allow" on the master > and "tls_reqcert=never" on the consumer. So it doesn't really verify the > certificates. (I might have overlooked something, took only a brief > glance at it). Ah, that sounds familiar. Closing this ITS. It's not a regression and not a bug, just a long established feature. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
