looking for terminology recommendations concerning non-rooted FQDNs

David Miller dmiller at tiggee.com
Mon Feb 25 16:55:53 UTC 2013


On 02/25/2013 11:47 AM, Owen DeLong wrote:
> 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.


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 at tiggee.com





More information about the NANOG mailing list