On 02/25/2013 11:47 AM, Owen DeLong wrote:
On Feb 25, 2013, at 6:30 AM, Brian Reichert <reich...@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
dmil...@tiggee.com
