[Date Prev][Date Next]
Re: (ITS#6838) TLS client will not accept certificate for 'localhost'
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6838) TLS client will not accept certificate for 'localhost'
- From: firstname.lastname@example.org
- Date: Fri, 18 Feb 2011 17:37:59 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
> Am Freitag 18 Februar 2011, 13:17:17 schrieb
>> On Fri, Feb 18, 2011 at 12:30:25AM +0000, email@example.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
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
>>> 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
>>> (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
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/