In message <15455394.7034.1361803759023.javamail.r...@benjamin.baylink.com>, Ja y Ashworth writes: > ----- Original Message ----- > > From: "Brian Reichert" <reich...@numachi.com> > > > On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote: > [I believe this is Brian, then Mark: ] > > > > When I did my initial development with OpenSSL, I observed: > > > > > > > > - If I did not have the rooted domain name in the SAN, then any SSL > > > > client stack would fail the verification if a rooted domain name > > > > was used to connect to the SSL server. > > > > > > Well you have a broken SSL client app. If it is accepting non legal > > > hostnames it should be normalising them before passing them to the > > > ssl layer. > > > > From what little research I've done (only OpenSSL), the SSL client > > is relying on getaddrinfo(3) to do name resolution. In turn, I > > haven't found an implementation of getaddrinfo(3) that rejects > > rooted domain names as non-legal.
And getaddrinfo() returns the canonical name (ai_canonname) which is the name found after searching, if any, and CNAMEs (DNAME) have been followed. It doesn't have a period at the end unless there is a implementation bug. struct addrinfo { int ai_flags; /* input flags */ int ai_family; /* protocol family for socket */ int ai_socktype; /* socket type */ int ai_protocol; /* protocol for socket */ socklen_t ai_addrlen; /* length of socket-address */ struct sockaddr *ai_addr; /* socket-address for socket */ char *ai_canonname; /* canonical name for service location */ struct addrinfo *ai_next; /* pointer to next in list */ }; Now http{s} clients and server administrators have misused CNAME for years so ai_canonname is not as useful as it should be. ai_canonname should match the expected name in the presented CERT. As a result the http{s} client needs to do the normalisation including search list processing. Yes there are lots of broken clients. > Yes, but that's not the question, Brian, assuming I understand the problem > as well as I think I do. The question is not how the client does the > name resolution on the client machine -- it's what it does with the domain > name it's looking up before doing the SSL interaction with the server side, > a process with which I'm not familiar enough to know if the client actually > send the host/domain name to the server end. Assuming it does -- and I > am -- the question is: should it take the dot off. > > === > > More formally: "is a host/domain name with a trailing dot *actually a > legal host name? No. See RFC 952 > Or is that merely local shorthand notation for resolvers > and DNS server zone files, to define absoluteness. In short: are domain > names on-the-wire *always* to be interpreted as absolute even in the > absence of a trailing dot." > > My personal opinion, based on about 2 decades of watching from the outside, > and of systems analysis and application design in non-internet contexts, > is to say that yes, they must; there is *in fact* no reason for a relative > domain name to leave a machine, since the context for it's relativity is > dependent on the resolv.conf on that machine for lookups, and on which > zone file it's in for service... > > and that the implication of that is that any application/library which > takes a text-string host/domain name handed to it from off-machine ought > to normalize away any trailing dot. > > I invite counter-arguments and -citations. :-) > > Cheers, > -- jr 'yeah, I know, it's Monday' a > -- > Jay R. Ashworth Baylink j...@baylink.co > m > Designer The Things I Think RFC 210 > 0 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DI > I > St Petersburg FL USA #natog +1 727 647 127 > 4 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org