2:01 a.m.
Quanah Gibson-Mount wrote:
For the test suite, I've generated a server cert with:
Subject: C=US, ST=CA, O=OpenLDAP Foundation, OU=OpenLDAP Test Suite, CN=localhost
and
X509v3 Subject Alternative Name:
DNS:localhost
slapd is listening as:
/home/build/git/symas-packages/thirdparty/openldap/build/UBUNTU16_64/symas-openldap/servers/slapd/.libs/lt-slapd
-s0 -f
/home/build/git/symas-packages/thirdparty/openldap/build/UBUNTU16_64/symas-openldap/tests/testrun/slapd.1.conf
-h ldap://localhost:9011/ ldaps://localhost:9012/ -d 0x4105
I.e., slapd is referring to itself as "localhost", and the cert fully refers
to itself as "localhost".
However, if I do a startTLS op to this host with reqcert set to "demand", it
fails with:
TLS: hostname (u16build) does not match common name in certificate (localhost).
Given that everything is using "localhost", it seems to me it should succeed
rather than fail, and that this error is incorrect.
The issue seems to be this if statement in tls_o.c:
if( ldap_int_hostname &&
( !name_in || !strcasecmp( name_in, "localhost" ) ) )
{
if I remove the check against the "localhost" name, things succeed as expected.
Fwiw, I routinely test with a localhost cert, and this check has never tripped
for me. But my ldap_int_hostname is also "localhost" - apparently something on
your system insists that your hostname is "u16build".
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8:09 a.m.
New subject: Bug in tlso_session_chkhost?
--On Tuesday, May 09, 2017 11:01 AM +0100 Howard Chu <hyc(a)symas.com> wrote:
> if I remove the check against the "localhost" name,
things succeed as
> expected.
Fwiw, I routinely test with a localhost cert, and this check has never
tripped for me. But my ldap_int_hostname is also "localhost" - apparently
something on your system insists that your hostname is "u16build".
One of the main tenants of the test suite is that it be portable. I think
mandating that anyone who wants to run the test suite must use a host with
a hostname set to "localhost" is untennable. Because of this bug, the test
suite will have to have a dependency on the "openssl" command line binary
so that it can generate certs based on the hostname of the system where it
is being run. Without this problematic code, we could simple check in
pre-generated certs, removing that dependency.
I do not see anything that indicates the check is actually valid, and
unfortunately the commit message makes no reference to any ITS or other
issue it supposedly fixes.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
11:43 a.m.
New subject: Bug in tlso_session_chkhost?
Quanah Gibson-Mount wrote:
--On Tuesday, May 09, 2017 11:01 AM +0100 Howard Chu
<hyc(a)symas.com> wrote:
>> if I remove the check against the "localhost" name, things succeed as
>> expected.
>
> Fwiw, I routinely test with a localhost cert, and this check has never
> tripped for me. But my ldap_int_hostname is also "localhost" - apparently
> something on your system insists that your hostname is "u16build".
One of the main tenants of the test suite is that it be portable. I think
mandating that anyone who wants to run the test suite must use a host with a
hostname set to "localhost" is untennable. Because of this bug, the test
suite will have to have a dependency on the "openssl" command line binary so
that it can generate certs based on the hostname of the system where it is
being run. Without this problematic code, we could simple check in
pre-generated certs, removing that dependency.
Well, technically your certDN is invalid. The cn is supposed to be the FQDN,
and in your case it must be "u16build.xxxx.yyy" or somesuch.
"subjectAltName"
means *alternative* name. It is totally correct for libldap to reject your
cert with a hostname mismatch when the cert cn is incorrect.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project
12:58 p.m.
New subject: Bug in tlso_session_chkhost?
Howard Chu wrote:
Quanah Gibson-Mount wrote:
> --On Tuesday, May 09, 2017 11:01 AM +0100 Howard Chu <hyc(a)symas.com> wrote:
>
>>> if I remove the check against the "localhost" name, things succeed
as
>>> expected.
>>
>> Fwiw, I routinely test with a localhost cert, and this check has never
>> tripped for me. But my ldap_int_hostname is also "localhost" -
apparently
>> something on your system insists that your hostname is "u16build".
>
> One of the main tenants of the test suite is that it be portable. I think
> mandating that anyone who wants to run the test suite must use a host with a
> hostname set to "localhost" is untennable. Because of this bug, the test
> suite will have to have a dependency on the "openssl" command line binary
so
> that it can generate certs based on the hostname of the system where it is
> being run. Without this problematic code, we could simple check in
> pre-generated certs, removing that dependency.
Well, technically your certDN is invalid. The cn is supposed to be the FQDN, and in
your case it must be "u16build.xxxx.yyy" or somesuch.
Hmm, this reminds me of Google Chrome enforcing at least *one* dot be used in a HTTP
cookie domain part. Otherwise it does not accept the cookie. For this purpose I have in
my /etc/hosts:
127.0.0.1 localhost localhost.localhost localhost.localdomain
Does your example above mean that you expect at least two dots?
That would be way too strict.
Also note that TLS client implementations today don't care about the subject-DN's
CN
attribute if the FQDN or IP address used by the client to establish the connection
already matched one of the subjectAltName values. AFAIK TLS client implementors are even
encouraged to rather ignore the misused CN attribute (which is IMO the right direction
today).
=> strictly requiring the CN attribute to contain a FQDN at all is IMO wrong if
subjectAltName already matched
"subjectAltName" means *alternative* name. It is totally
correct for libldap to reject
your cert with a hostname mismatch when the cert cn is incorrect.
Human language can cause misunderstandings. So maybe I misread your statement. But
I'm
reading your sentence that the CN must always match or at least be a FQDN even if a
subjectAltName value already matched.
Ciao, Michael.
2337
days inactive
2337
days old
3 comments
3 participants
participants (3)
-
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount