----- Original Message -----
From: "Brian Reichert" <reichert@numachi.com>
My understanding is this:
Unless you're doing client certificate verification (wherein the server is making decisions about which clients attempting a connection), all validation/verification is done by the client.
Right; my apologies; I know better than to post Before Coffee. :-)
The SSL client retrieves the server's certificate, and the set of values in the Subject and the Subject Alternative Name is compared against the hostname/IP address used to initiate the process. This comparison is (to my understanding) straight-forward (modulo UTF8 encodings, etc.).
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. 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. 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