Hello, On 08.12.2010 12:48, Tom Evans wrote:
Until the incoming request has been received and decrypted, apache has no clue that the domain requested was 'not-ssl-configured-domain.xx'. That's kind of the point of SSL.
Ok, thanks for pointing that out.
Apache determines which vhost to use to send certificates from based on the ip:port, since no other information is available.
Makes perfect sense.
Because of this, if you have two hosts, www.hosta.com and www.hostb.com, that resolve to the same IP address, and configure SSL for www.hosta.com, then requesting www.hostb.com via SSL will connect and handshake using certificates from www.hosta.com ...
Fine so far ...
... and serve data from the www.hosta.com vhost.
.. but at this point apache knows that there is something wrong with the request or the configuration, and should throw an error instead of serving the wrong data.
It's not quirky, it's a direct consequence of how things work, ..
Look at my "solution" - having to define a dummy-vhost to catch the ssl-requests for all domains not explicitely ssl-defined, in order to restrain the service to the one domain it was meant for. At least at this point a kind of "ServerName ... exclusive" directive for the config (and logic behind) could make sense, or maybe it exists and my weary eyes overread it.
/ Bernd --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|