It's an ingenious attempt and it may seem to work but there is a lot going on that you might not be aware of. Consider what happens when someone types "https://domain2/"; into their browser:
- the browser gets the IP address for domain2 (which is the same IP address as domain1) and then sends a packet to port 433 at that address requesting an SSL session. - the server receives an SSL request on port 443. That's all it gets. So what VH is it to use? By default, it just looks in the first one - so it sends "domain1.cert". - the browser gets the cert and opens it. "That's funny", thinks the browser, "I asked for domain2, but this cert is for domain1... I'd better warn my master". So it pops up an alert window warning you that "the certificate does not match the site name". You have to click OK. - the browser is reassured so continues with the SSL channel setup. It then requests the webpage from the server. - the server gets the encrypted request and, since it now has a working SSL channel, decrypts it. Now it can see inside and get the host header. So at last it can see that he request is for domain2. So it goes into the domain2 VH where it hits the rewrite rule! So it sends a redirect to send the browser to domain2:444. - The browser gets the redirect and off it goes to domain2:444. This time there is no ambiguity since there is only one VH. So it gets the correct cert, sends it to the browser and this time there is no warning because now the site and cert match. The point of the story is that you are still using the "wrong" cert to set up the initial SSL channel. Unless you define the port in the original request, there is no way to get the server to identify the correct VH - it will always use the first one. To put it another way, you don't really need to bother with the VH on port 444 - if you don't mind that the session is established with the domain1 cert, you can just leave it and after the SSL channel is established name-based VH will work. Alternatively, you can put the rewrite rule into the domain1 VH (though you need to change it so it trips on the servername) and dispense with the domain2:443 VH. The trouble with using the "wrong" cert is that it is not a general solution since it violates the authentication aspect of SSL. SSL is not only about encryption, it is also about ensuring that the site you are talking to is authentic. Encryption is like sending your money to the bank in an armoured car. Authentication is making sure the armoured car really does go to the bank. Rgds, Owen Boyle >-----Original Message----- >From: fred [mailto:fred@;skyturn.net] >Sent: Donnerstag, 7. November 2002 18:54 >To: [EMAIL PROTECTED] >Subject: Re: ModSSL and VirtualHosts > > >Hello, I was the first one (of today) >I anderstand your ###!!!???. Its ###:::/??? to repeat ten >times the same >thing. I hope that my answer will help people to configure >multi ssl with one >IP. >Personaly I can not have an other IP so I use the same ip >whith different >port and I use mod Rewrite to redirect to the new port and it >work very well. >ex: ><IfDefine SSL> >Listen *:80 >Listen *:443 >Listen *:444 ></IfDefine> > >NameVirtualHost MY_IP:443 > ><VirtualHost MY_IP:443> > DocumentRoot "/home/web/SSL/dmaine1/htdocs" > ServerName domaine1 > ServerAdmin root@localhost > SSLEngine on > SSLCipherSuite >ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL > SSLCertificateFile /usr/local/apache/conf/ssl.crt/domaine1.crt > SSLCertificateKeyFile /usr/local/apache/conf/ssl.key/domaine1.key > <Files ~ "\.(cgi|shtml|phtml|php3?)$"> > SSLOptions +StdEnvVars > </Files> > <Directory "/usr/local/apache/cgi-bin"> > SSLOptions +StdEnvVars > </Directory> > SetEnvIf User-Agent ".*MSIE.*" \ > nokeepalive ssl-unclean-shutdown \ > downgrade-1.0 force-response-1.0 > CustomLog /usr/local/apache/logs/ssl_request_log \ > "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" ></VirtualHost> ><VirtualHost MY_IP:443> > DocumentRoot "/home/web/SSL/domaine2/htdocs" > ServerName domaine2 > ServerAdmin root@localhost > RewriteEngine On > RewriteRule ^/(.*)$ https://domaine2:444/$1 [R] > SSLEngine on > SSLCipherSuite >ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL > SSLCertificateFile /usr/local/apache/conf/ssl.crt/domaine2.crt > SSLCertificateKeyFile /usr/local/apache/conf/ssl.key/domaine2.key > <Files ~ "\.(cgi|shtml|phtml|php3?)$"> > SSLOptions +StdEnvVars > </Files> > <Directory "/usr/local/apache/cgi-bin"> > SSLOptions +StdEnvVars > </Directory> > SetEnvIf User-Agent ".*MSIE.*" \ > nokeepalive ssl-unclean-shutdown \ > downgrade-1.0 force-response-1.0 > CustomLog /usr/local/apache/logs/ssl_request_log \ > "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" ></VirtualHost> > ><VirtualHost MY_IP:444> > DocumentRoot "/home/web/SSL/domaine2/htdocs" > ServerName domaine2 > ServerAdmin root@localhost > SSLEngine on > SSLCipherSuite >ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL > SSLCertificateFile /usr/local/apache/conf/ssl.crt/domaine2.crt > SSLCertificateKeyFile /usr/local/apache/conf/ssl.key/domaine2.key > <Files ~ "\.(cgi|shtml|phtml|php3?)$"> > SSLOptions +StdEnvVars > </Files> > <Directory "/usr/local/apache/cgi-bin"> > SSLOptions +StdEnvVars > </Directory> > SetEnvIf User-Agent ".*MSIE.*" \ > nokeepalive ssl-unclean-shutdown \ > downgrade-1.0 force-response-1.0 > CustomLog /usr/local/apache/logs/ssl_request_log \ > "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" ></VirtualHost> > > > >On Thursday 7 November 2002 18:21, you wrote: >> Sorry. That last post was harsh - it's been a long day. But everyone >> (including me) who moves into SSL immediately wonders why >name-based VHs >> don't work. You are the second person *today* to ask this... >> >> The problem is that the packet is encrypted so apache can't >see the Host >> header so doesn't know what VH to use. But it needs the VH >in order to >> decide on the cert - it's a classic Catch-22. There is no >workaround (we >> had a guy today trying rewrite rules - marks for originality, but no >> cigar). You have to use separate IPs or ports... >> >> Rgds, >> >> Owen Boyle >> >> >-----Original Message----- >> >> From: Alex [mailto:alex@;damngeek.com] >> >> >Sent: Donnerstag, 7. November 2002 17:55 >> >To: [EMAIL PROTECTED] >> >Subject: ModSSL and VirtualHosts >> > >> > >> >I think I'm missing a few key points here, so I'm not able >to find the >> >answers by myself. Hate to sound like a newbie, but I'm >> >getting a little >> >frustrated. >> > >> >Lets say I have this: >> > >> ><VirtualHost *> >> >DocumentRoot /usr/local/www/domain1 >> >ServerName domain1.dom >> ></VirtualHost> >> > >> ><VirtualHost *> >> >DocumentRoot /usr/local/www/wwwdomain1 >> >ServerName www.domain1.dom >> ></VirtualHost> >> > >> > >> >This works just great, both sites would show up and show the correct >> >directory. I can use the * or the ip address for the >VirtualHost, both >> >with the same results. >> > >> >All I can get with the https://... is the default directory >> >saying apache >> >is installed. Now I can change the default directory in the >VirtualHost >> >for _default_:443 and it will point to which ever directory I >> >want, with >> >ssl. >> > >> >How do I get https://domain1.dom the same as http://domain1.dom, and >> >https://www.domain1.dom the same as http://www.domain1.dom? >> > >> >Or is it by design only to work with one directory? >> > >> > >> >Oh, and to possibly add to any confusion, this is a freebsd >> >4.7 box with >> >a private ip (firewalled) with apache+mod_ssl-1.3.27+2.8.12. >> > >> >Any help would be appreciated. >> > >> >Thanks for your time. >> > >> >>______________________________________________________________________ >> >Apache Interface to OpenSSL (mod_ssl) www.modssl.org > >User Support Mailing List [EMAIL PROTECTED] > >Automated List Manager [EMAIL PROTECTED] > > This message is for the named person's use only. It may contain > confidential, proprietary or legally privileged information. No > confidentiality or privilege is waived or lost by any mistransmission. > If you receive this message in error, please notify the sender urgently > and then immediately delete the message and any copies of it from your > system. Please also immediately destroy any hardcopies of the message. > You must not, directly or indirectly, use, disclose, distribute, print, > or copy any part of this message if you are not the intended recipient. > The sender's company reserves the right to monitor all e-mail > communications through their networks. Any views expressed in this > message are those of the individual sender, except where the message > states otherwise and the sender is authorised to state them to be the > views of the sender's company. > ______________________________________________________________________ > 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] This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company. ______________________________________________________________________ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
