--On Wednesday, May 10, 2017 7:01 PM +0200 Michael Ströder michael@stroeder.com wrote:
Quanah Gibson-Mount wrote:
--On Wednesday, May 10, 2017 4:21 PM +0100 Howard Chu hyc@symas.com wrote:
No. One or the other must match, but the CN must be an FQDN. The point of alternatives is to support wildcards, aliases, and non-DNS name forms (such as IP address).
RFC reference?
RFC 6125 which in turn mentions RFC 4513.
Thanks.
From RFC 6125:
6.4.4. Checking of Common Names
As noted, a client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client.
Therefore, as I noted, the certcn is immaterial since I have a DNS: value specified, and it is then required that the certcn be ignored. The rest of the RFC doesn't really cover special cases like localhost. I still see nothing in the RFC that states what's I'm doing is invalid. It does appear to be outside of what's normally done, but that's not surprising.
--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 Wednesday, May 10, 2017 7:01 PM +0200 Michael Ströder michael@stroeder.com wrote:
Quanah Gibson-Mount wrote:
--On Wednesday, May 10, 2017 4:21 PM +0100 Howard Chu hyc@symas.com wrote:
No. One or the other must match, but the CN must be an FQDN. The point of alternatives is to support wildcards, aliases, and non-DNS name forms (such as IP address).
RFC reference?
RFC 6125 which in turn mentions RFC 4513.
Thanks.
From RFC 6125:
6.4.4. Checking of Common Names
As noted, a client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client.
Therefore, as I noted, the certcn is immaterial since I have a DNS: value specified, and it is then required that the certcn be ignored. The rest of the RFC doesn't really cover special cases like localhost. I still see nothing in the RFC that states what's I'm doing is invalid. It does appear to be outside of what's normally done, but that's not surprising.
The point is there is nothing on your machine that says your hostname is "localhost". Therefore, since the subjectAltName of DNS:localhost doesn't match any known name for your host, the cert is rejected.
--On Wednesday, May 10, 2017 7:02 PM +0100 Howard Chu hyc@symas.com wrote:
The point is there is nothing on your machine that says your hostname is "localhost". Therefore, since the subjectAltName of DNS:localhost doesn't match any known name for your host, the cert is rejected.
Sure there is, /etc/hosts. And as I noted, per RFC 6761, "localhost." is a recognized domain. The OpenLDAP code is incorrect.
A better solution would be for the localhost case to check if (a) the cert has a match, and if it fails, then fall back to see if it matches ldap_int_hostname.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Howard Chu wrote:
The point is there is nothing on your machine that says your hostname is "localhost". Therefore, since the subjectAltName of DNS:localhost doesn't match any known name for your host, the cert is rejected.
The machine's hostname is completely irrelevant.
The TLS hostname MUST check the hostname the client used to successfully establish the connection and nothing else.
Ciao, Michael.
-
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount