Oh yeah, we’ve *all* done it at one time or another … heck, I’m probably doing it now!
What am I doing? I’m making Apache work with bad configurations! Why? Ummm… So, anyway, check out this page … I don’t know how I haven’t found it before, but it’s brilliant. It clears up so many of the questions that the general Apache documentation seems to create (for me):
One thing that this web page cleared up for me, which was amazing it took this long, was the simple fact that NameVirtualHost does NOT mean the “name” of the vhost, it means the IP that said vhost lives one!
Normally, “ehhh”, right? But, when you start dealing with SSL and multiple interfaces (eth0, eth1, etc or eth0, eth0:1, eth0:2, etc) it starts to matter a LOT! You cannot connect to any interface and have Apache find the right SSL vhost and certificate properly. When it does work, it’s just dumb luck.
NameVirtualHost *:443 <VirtualHost *:443> ServerName some.domain.com # SSL options, other options, and stuff defined here. </VirtualHost> <VirtualHost *:443> ServerName some.domain2.com # SSL options, other options, and stuff defined here. </VirtualHost>
Yes, your client can attach, and yes, your client can get an SSL connection and cert information, *however* any access to some.domain2.com will throw errors because the cert for some.domain2.com does *not* match some.domain.com, and that’s the one that apache will initiate the conversation with! DOH!
NameVirtualHost 18.104.22.168:443 <VirtualHost 22.214.171.124:443> ServerName some.domain.com # SSL options, other options, and stuff defined here. </VirtualHost>
NameVirtualHost 126.96.36.199:443 <VirtualHost 188.8.131.52:443> ServerName some.domain2.com # SSL options, other options, and stuff defined here. </VirtualHost>
Will give you the results you want. Yes, it sucks to hardcode IPs in a config file … Your other option is to do the hostname in both and make sure that the *host* resolves that name to the IP you want.
Another gotcha that I ran into lately was *with* using the hostnames in my <NameVirtualHost> and <VirtualHost> was on AWS. Because AWS uses an internal VPS IP on the host (you have to add an IP per SSL site), and a public Elastic IP on the outside, when I originally put in the hostname in the <NameVirtualHost> it didn’t work. Why? Because the hostname resolved to the public IP, not the internal 172.x.x.x interface! Double-DOH!
I ended up putting the internal IPs in the local /etc/hosts files as they corresponded to the external IPs … not a great solution, but it was the best I could think of after a long day. This at least allows me to keep the vhost configurations generic enough that I can propagate multiple webservers as needed with the same config, assuming the host knows about it’s private<->public IP mapping somehow. An internal/private network DNS layer would probably be a better solution.
Thanks to Matt Simmons for his blog entry that lead me to this nugget of fun wisdom!