--On Wednesday, May 10, 2017 10:11 AM -0700 Quanah Gibson-Mount quanah@symas.com wrote:
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.
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.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
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.)
-
Quanah Gibson-Mount -
Ryan Tandy