[161071] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: looking for terminology recommendations concerning non-rooted

daemon@ATHENA.MIT.EDU (David Miller)
Mon Feb 25 11:56:07 2013

Date: Mon, 25 Feb 2013 11:55:53 -0500
From: David Miller <dmiller@tiggee.com>
To: nanog@nanog.org
In-Reply-To: <74F5F4AD-935B-442D-86CC-9CB19B880123@delong.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

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



home help back first fref pref prev next nref lref last post