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:localhostslapd 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".
--On Tuesday, May 09, 2017 11:01 AM +0100 Howard Chu hyc@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
Quanah Gibson-Mount wrote:
--On Tuesday, May 09, 2017 11:01 AM +0100 Howard Chu hyc@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 wrote:
Quanah Gibson-Mount wrote:
--On Tuesday, May 09, 2017 11:01 AM +0100 Howard Chu hyc@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.
-
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount