[Date Prev][Date Next] [Chronological] [Thread] [Top]

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



rhafer@suse.de wrote:
> Am Freitag 18 Februar 2011, 13:17:17 schrieb
> andrew.findlay@skills-1st.co.uk:
>> On Fri, Feb 18, 2011 at 12:30:25AM +0000, hyc@symas.com 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/