[161070] in North American Network Operators' Group
Re: looking for terminology recommendations concerning non-rooted
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Feb 25 11:53:04 2013
From: Owen DeLong <owen@delong.com>
In-Reply-To: <20130225143034.GN99258@numachi.com>
Date: Mon, 25 Feb 2013 08:47:44 -0800
To: Brian Reichert <reichert@numachi.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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:
>>>=20
>>> - 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.
>>=20
>> 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.
>=20
>> =46rom 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.
>=20
getaddrinfo should not reject foo.blah.com. or foo.blah.com. However,
it will use the data=85 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
