On Mon, Feb 25, 2013 at 11:26:47AM -0500, Jay Ashworth wrote:
The upshot (assuming I'm not totally off base here), is that other than getaddrinfo(), nothing is acting on the semantics of the supplied hostname (or IP address). They are 'just strings', and are (essentially) compared as such.
Right. And I'm asserting that that's wrong: the client side libraries Really Ought To normalize that name before trying to compare it against the retrieved certificate to see if it matches, which would relieve you of having to have the altName with the trailing dot in such a cert.
I know for internal testing, I've had to introduce unqualified hostnames in the CSR as well (e.g. 'testhost', instead of 'testhost.example.com'), to handle the case of the client not using domain names at all (when framing queries). This illustrates that there's not even an effort to synthesize a FQDN. Who should implement the normalization logic? Not the SSL library, certainly. That sounds like the bailiwick of the resolver library...
The controlling standard *appears* to be RFC 2246, TLS v1.0. I'm doing some work this morning, but that's up in a tab for coffee breaks; I'll try to figure out what I think Dierks and Allen thought about this topic, if anything, during the day.
I look forward to the fruits of your research. :)
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large