Re: looking for terminology recommendations concerning non-rooted FQDNs

[David Miller <dmiller () tiggee com>]

On 02/25/2013 11:47 AM, Owen DeLong wrote:
> On Feb 25, 2013, at 6:30 AM, Brian Reichert <reichert () numachi com> wrote:
>
> > On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote:
> > > > 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.
> getaddrinfo should not reject foo.blah.com. or foo.blah.com. However,
> it will use the data… foo.blah.com will have the domain search strings
> (if any) appended, so for example, if your search configuration is
> "blah.com, example.com", then it will search for foo.blah.com.blah.com.,
> foo.blah.com.example.com., and foo.blah.com. until it finds a match.


The lookup order should be foo.blah.com, foo.blah.com.blah.com, 
foo.blah.com.example.com ?


> However, that's for the resolver library. In terms of matching the CN
> in a certificate, this should always be FQDN and the trailing dot
> should not be present.  If OpenSSL (the command line tool) is passing
> foo.blah.com. to the SSL functions and not just getaddrinfo(), then,
> it is a bug.
>
>
> Owen


--
-______________________
David Miller
dmiller () tiggee com