> From: André Warnier [mailto:[EMAIL PROTECTED]
> As I remember from reading about this a while ago, there is/was a
> fundamental incompatibility between the HTTP Virtual Host
> mechanism, and
> HTTPS/SSL, in the sense that there is some egg-and-chicken problem
> involved, which roughly goes like this :
> - the client connects to the host and requests an encrypted connection
> to a certain hostname
Almost. The client connects to the host on a given IP address and port, which
requires an encrypted connection. No hostname is transferred at this point, as
encryption must happen first.
> - the host and client negociate the encryption (based or not
> on the name of the host)
Based on the certificate that the host sends to the client as part of
negotiating the encryption. That certificate contains the common name of the
host (or occasionally a wildcard name such as *.melandra.com). The client
should be suspicious if the common name in the certificate does not match the
hostname the client thinks it sent the request to.
Therefore, the host cannot know to which virtual host the client wishes to
connect when it sends the certificate.
Therefore, the host cannot send the "right" certificate unless all requests to
a given hostname and port are designed to use the same certificate.
Therefore, virtual hosting using SSL is a problem.
> Is the above, very roughly and approximatively still a valid
> explanation
> of what happens, or is it totally wrong, or has something changed
> in-between that I am unaware of ?
It's close, but the problem occurs at an earlier step than you outline :-).
- Peter
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
