On Tue, Oct 22, 2013 at 9:10 AM, Chris Gordon <cgor...@aires.com> wrote:
> SSL wraps http and you need a cert to decrypt the data sent via SSL. If > you have 3 virtual hosts and you are using Name Based Virtual Hosting how > does the Apache web server know which cert to use to decrypt and read the > header so it can properly route the data. The short answer per my > understanding is that Apache has no clue and uses the default vhost's > cert (the first one in the confi file) to read the SSL. If these were all > the same domain such as tuna.foo.com, seabass.foo.com and marlin.foo.comyou > could get away with using the same *. > foo.com wildcard cert. Here is a good doc with these work arounds: > https://www.switch.ch/pki/meetings/2007-01/namebased_ssl_virtualhosts.pdf > > I'm guessing your problem is somewhere in this domain. I believe that > Name Based Virtual Hosting is not the answer for you. Try IP Based: > http://httpd.apache.org/docs/2.2/vhosts/ip-based.html > If that were the case, the browser would show a certificate error on all but one host, not a partial error on just one of them. I would go with Pete's answer first (that there might be images or javascript served from http). > or use a wildcard cert... Here is a warning about your config and a > better explanation I presume: > http://wiki.apache.org/httpd/NameBasedSSLVHosts > > I just ran into this. Silly me for not realizing that a Web Server that > routes bases on headers would need to read the encrypted header to route > it. Chicken-Egg problem. > There is a solution for this which Apache supports: Server Name Indication (SNI) This lets the browser send the domain name requested before Apache chooses a certificate to help it choose the correct one. See http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI - Y
