On Wed, Dec 12, 2012 at 11:43 AM, José Francisco Álvarez Aguilar <pepinsoftware@xxxxxxxxxxx> wrote: > 2012/12/12 Tom Evans <tevans.uk@xxxxxxxxxxxxxx> >> >> It "works" just fine, you are just not understanding what is necessary >> for it to work. >> >> VirtualHost uses the Host header supplied in the request to best >> determine the website to route the request to. >> >> In order to read headers in an SSL request you need to decrypt the >> encrypted request. >> >> In order to decrypt the request, you need to know what key was used to >> encrypt the request, which depends upon which host name the request >> was sent to, >> >> Apache cannot work this out, and so uses the configuration from the >> default vhost for that IP/port combo. If this certificate matches, >> then the request works, and it can use the Host header to route the >> request to the appropriate vhost. >> >> Therefore, if you can setup your vhosts so they share the same SSL >> certificates - either using wildcard certificates, or using >> subjectAltName certificates - then they can share the same IP. >> >> If you can't do this, then they can't share the same IP. This is not a >> limitation of Apache. >> >> Cheers >> >> Tom >> >> If you can setup your site. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx >> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx >> >> > > I understand what you mean. Maybe I did not explain myself properly. (using > a foreign language is always a barrier) I understand the difficulties! If we both keep talking, we might make each other understand though, so lets plough through. > > > Just imagine we have 3 vhost redirected to 3 different machines everyone > with different IP. (it doesn't matter if it's using SSL or not). > If one of this three machine is switched off and apache receives a request > for that one.... it's supposed that the client should receive "Page not > found", isn't it? or apache will send the first vhost available? if so... it > shouldn't. So, we're no longer talking about SSL, but about vhosts in general? A request comes in. The address and port the request comes in on are compared to the NameVirtualHost settings - does it match. If it does, it steps through all vhosts matching the NameVirtualHost that the request matched If a vhost's ServerName or ServerAlias matches the requests Host header, serve from that vhost If no vhost matches the Host header, serve the first vhost listed in the configuration file that matches the NameVirtualHost matched from the incoming request. If there is no matching vhost, or no NameVirtualHost match, serve the first vhost If there is no vhost at all, serve the stock configuration > > In the other hand, if we have a lonely apache server listening only on 443 > and if someone sends a request to 80, receives "Page not found" because no > one is listening on 80. And viceversa: if a lonely server is listening on 80 > and someone sends a request to 443, should receive "Page not found". If it's not listening on 80, you get 'connection refused', not a http error response. If it is listening on 80, it serves as apache always serves. > > If we put together this two lonely machines throught vhost.... apache > *should behave transparently*, the way the client doesn't know how many > machines (real or virtual) are behind our service... > And that holds true IF AND ONLY IF you are not using SSL. At $JOB, we serve all our websites - around 600-700 sites - through a pair of httpd reverse proxies that talk to the actual web server. We can have any number of webservers behind these two proxies, and our users are none the wiser. The SSL issues are still there, we use wildcard certificates for each domain requiring SSL, and use a separate IP for each wildcard domain, and use effectively name based SSL virtual hosts. Eg, foo.dom.com and bar.dom.com are served from the same IP, using the same SSL certificates. Cheers Tom --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|