> However, the problem is that (as I understand it):
>
> - the GET request for the SSL page comes in already encrypted (the
> browser knows to encrypt it because the URL begins with "https").
> - The server tries to do virtual host resolution first so tries to find
> the ServerName in the request.
> - Since the request is encrypted, it can't get the ServerName.
> - Without the ServerName, it doesn't know which VirtualHost to use.
> - So it can't start the SSL engine since it hasn't seen an "SSLEngine
> On" directive because this is in the SSL virtual host definition.
> - So we've come full circle and we're stuck.
This is not actually the problem, although very close.
What happens is the client browser sees https so it thinks 'Ah, SSL on port 443'
So it connects to the web server and sets up an SSL connection. There is no GET
or POST or HTTP at all. This is still the SSL stage. The problem is, all the
web server knows, and more specifically - all mod_ssl knows, is that a
connection is coming in on IP: X and Port: Y (here 443). So the server needs to
find a configuration using only the IP address and the Port number. If you use
NBVH and these virtual hosts do not have unique IP+Port combinations, then the
web server will not know which one it should use to determine which key should
be used for encryption/decryption. Typically it will just pick the first one it
gets to, which means one of the NBVH will be fine, but the other will use the
wrong key - so most high profile clients will throw an error saying that the
certificate dns name does not match the url dns name. You still get a perfectly
good SSL connection, its just that the certificate sent out is not the one you
wanted. The solution is, if you need NBVH for SSL connections, they should have
unique IP+Port combinations.
Your problem below shouldnt be a problem, because although you have NBVH, you
only have 1 SSL virtual host. There should be no problems in that case.
(although, it is generally a good idea to explicitly state your ip+port for
each virtual host, or use _default_).
Dana Powers
>
> The Solution:
> -------------
>
> The recommended solution is to use a different IP address for the SSL
> virtual host. This would obviously solve the problem since the server
> can go immediately to the SSL VirtualHost as soon as it receives a
> request on that IP address - no need to look in the request for a
> ServerName. It then sees it has to start SSL and we're off.
>
> However, the solution I tried was to define the port numbers explicitly
> when declaring the IP addresses. The config file is then:
>
> NameVirtualHost 192.168.200.1:80
>
> <VirtualHost 192.168.200.1:80>
> ServerName banana.fruit.com
> DocumentRoot /home/banana
> </VirtualHost>
>
> <VirtualHost 192.168.200.1:80>
> ServerName kiwi.fruit.com
> DocumentRoot /home/kiwi
> </VirtualHost>
>
> <VirtualHost 192.168.200.1:443>
> ServerName ssl.fruit.com
> DocumentRoot /home/ssl
> SSLEngine On
> </VirtualHost>
>
> Now, I guess, the server uses the port number to decide whether to do
> name-based virtual host resolution and if it receives a request on port
> 443 it does not attempt NBVH.
>
> This seems to work for me and I'd be interested to hear if anyone knows
> of any pitfalls of this approach.
>
> Best regards,
>
> Owen Boyle.
>
> --
> SWX Swiss Exchange, 10 Cours de Rive, 1211 Geneve 3
> --------------------------+-------------------------
> Phone: +41 (0)22 849 5648 | Fax: +41 (0)22 849 5643
> ______________________________________________________________________
> Apache Interface to OpenSSL (mod_ssl) www.modssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
