[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Bug in tlso_session_chkhost?
- To: openldap-devel@openldap.org
- Subject: Re: Bug in tlso_session_chkhost?
- From: Ryan Tandy <ryan@nardis.ca>
- Date: Wed, 10 May 2017 09:49:34 -0700
- Content-disposition: inline
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nardis.ca; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=WnaRvXNtA/WbvkxpgSra/UODJeqMCwhX2az/vRqgnkA=; b=fNAstp4HlsFj5ssJdwUCIyaQ3bju+LLtDux4lE6Cif/NYgaetczU3DSzCJ0/OfIuAa ByxfOExEmP2sU5Jz/az+xRCHDcea3MiY1F0viwynZBPlqVLXPtlNS3YCooAmtqx8ml4U QKlce3+xasCLP2vSR/VSqiHtUnzTZDMl4apT8=
- In-reply-to: <81701E14952167B6E8E32381@[192.168.1.19]>
- References: <71671977-6211-348b-c8ac-586d4af0e031@stroeder.com> <WM!f23f84644cc0e2f103ba5c9aba1bd61059b687261a1c4293c1677863d7668e3bac63d2fb954d030905651563e1e4d1db!@mailstronghold-2.zmailcloud.com> <2817658C7EA0A04BD6B8FA96@[192.168.1.19]> <60b094bf-a6b5-0dd7-d9c8-1aa25c765ebb@symas.com> <18BEB0EE5AD7F275CA3F4C6C@[192.168.1.19]> <7c8f2d5d-c189-8cb8-6c85-c322ac9d0df4@stroeder.com> <WM!770ed6a5d960360597ba3e402bfccdf09b18b96e6c6eb2bce2af8c9a08adcc603344ea35d82d0a31dddc85006980c642!@mailstronghold-1.zmailcloud.com> <A32F20071B8440F8CBA43B4D@[192.168.1.19]> <WM!42c3ba3dcf596e6dd0bda2effc112f7dab8fe3d1c290c959d1c4d15622a11cb9e27d0712e325e20c3ece9ad2b781f02e!@mailstronghold-3.zmailcloud.com> <81701E14952167B6E8E32381@[192.168.1.19]>
- User-agent: Mutt/1.5.23 (2014-03-12)
On Wed, May 10, 2017 at 09:32:59AM -0700, Quanah Gibson-Mount wrote:
RFC 6761 specifically notes that "localhost." is in fact a domain name
(Section 6.3). Therefore, my certificates are in fact correct, and
the OpenLDAP code check is indeed a bug.
"localhost." is a perfectly valid FQDN (as is the relatively common
"localhost.localdomain."), but from earlier in the thread I gathered
your system's FQDN is actually "u16build." or "u16build.some.domain.".
Does the FQDN (aka ldap_int_hostname) actually match one of the SANs in
the certificate? The first time I tried your branch, the only reason it
reached the CN check at all was because none of the SANs matched.
(But there may be a tiny bug if we're looking at CN at all when the cert
contains a SAN. That sounds like it might be contrary to the RFC.)