Am Freitag 18 Februar 2011, 13:17:17 schrieb
On Fri, Feb 18, 2011 at 12:30:25AM +0000, hyc(a)symas.com wrote:
> Used to work - since when, what release, what else has changed since
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
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
All versions that I have tested (certainly back to 2.3.32)
fail to connect when the URL is ldap://localhost:1389/ and a CA cert
Yes, AFAIK libldap's behavior of trying to figure out the machines
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.
> I'll note that I just tested some localhost certs a few days
> fine, and the cert verification code hasn't changed in quite
> (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).