looking for terminology recommendations concerning non-rooted FQDNs

Mon Feb 25 16:47:44 UTC 2013

On Feb 25, 2013, at 6:30 AM, Brian Reichert <reichert at 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.

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