6

I have a virtual sever which I would like to point two domains to, both pointing to different sites.

For example, example1.com goes to /var/www/example1. example2.com goes to /var/www/example2.

I can do this just fine with VirtualHosts:

<VirtualHost *:80>
    ServerName example1.com
    DocumentRoot "/var/www/example1"
</VirtualHost>

<VirtualHost *:80>
    ServerName example2.com
    DocumentRoot "/var/www/example2"
</VirtualHost>

My first question is to do with the leading www. In order to enable support for the www, I have just added a ServerAlias:

<VirtualHost *:80>
    ServerName example1.com
    ServerAlias www.example1.com
    DocumentRoot "/var/www/example1"
</VirtualHost>

Is this the best way to do this?

My second question involves SSL. I would also like example2.com to be accessed via SSL: https://example2.com. I have issued the certificate etc, but how would I achieve this in my httpd.conf file? At the moment I have a temporary workaround. I have just changed the server's main DocumentRoot to point to this /var/www/example2. I understand that SSL is on a different port so it will not be interpreted by the VirtualHost definition, so I have done this as a quick workaround. However, I would like to know what the best way to do this is?

Oliver Joseph Ash
  • 361
  • 3
  • 5
  • 14

2 Answers2

9
  1. yes - ServerAlias is the standard way to achieve that. Sometimes it is preferred to select the www.myserver.com as the "most preferred" identity and have "myserver.com" as the alias, but it really makes no different unless you canonicalise (convert links to preferred ones) URLs at some point.

    2.

Edit: it seems that I misunderstood the OP question, so this is mostly irrelevant

short answer (for hosting multiple SSL sites on one apache server)

  • the simplest solution, is IP based virtual hosts... supports all browsers - ask your ISP for a second IP address. So you have 1 IP per SSL cert. See below for example config.

  • Server name indication - not XP or old safari, or old android - works with only 1 IP - http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

Long answer (and boy I did get carried away with this answer... ;-) here is a quick primer on SSL and name virtual hostings....

Name based virtual hosting, is a strategy of sharing the web server between web sites based on the "Host" header presented by the client, (ie the web browser etc).

This is a HTTP 1.1 extension, and to use it apache reads the content of the request and parses the header, ie it looks like this;

GET /index.htm HTTP/1.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0
Host: www.google.co.uk            <--  apache checks this value 

However with the TLS handshake used in SSL connections the server indentifies itself before the Host header is sent, using the "common name" field in the SSL certificate.

Hence (using traditional... SSL v1, old browsers etc, Windows XP) there can only be 1 SSL identity per IP address, because the first thing the server does is identify itself as say www.amazon.com, which it cannot change afterwards...

Basically the differences is like so, in normal http://myserver.com requests

client: hello server   
server: hello client   
client: please give me web XXX   
server: here is websiteXXX    

but for https:// requests it is more like this;

client: hello server   
server: I am website XXX   
client: ok, go ahead and give me website XXX   
server: here is websiteXXX   

So basically, for a "supporting all browsers", including crufty old ones solution, You need to ask your ISP for another public IP address and then bind your second virtual host to the second ip instead of the first...

However there are some alternatives, which allow multiple SSL identities on a single IP address that work on most modern browsers, for example SNI or wildcard certs.

  • wildcard certs, not suitable in this particular situation because the servers names are domain level, eg badger.com and monkey.com, rather than badger.server.com and monkey.server.com

however with Server Name Indication, you tell the server which Host you want, during the handshake process and the server can provide the correct certificate. It appears that the server will fall back to the default cert, so might be a good strategy when you have a "primary" SSL site, and a less important one which you can accept some loss of user requests.

Basically the directives for adding SSL virtual hosts are similar, except that you are adding just plain virtual Hosts, rather than NameVirtualHosts.

#if not done elsewhere in httpd.conf incldue these
Listen 443
LoadModule ssl_module   modules/mod_ssl.so

#this does work for wildcard SSL certs like *.myserver.com (and SNI???)
NameVirtualHost *:443

<VirtualHost 1.1.1.1:443>
  SSLEngine On
  ServerName address1.com
  DocumentRoot /var/www/adderss2
  SSLCertificateFile /etc/httpd/conf/domaina_ssl/zimbra.zmb.moc.crt
</VirtualHost>

<VirtualHost 1.1.1.2:443>
  SSLEngine on
  ServerName address2.com
  DocumentRoot /var/www/adderss2
  SSLCertificateFile /etc/apache2/ssl/apache.pem
</VirtualHost>
Tom
  • 11,176
  • 5
  • 41
  • 63
  • Thanks, great explanation. Given those circumstances, what solution would you advise? – Oliver Joseph Ash Mar 06 '12 at 22:30
  • Using wildcard or SAN certs, you can have distinct sites, on the same IP, using the same cert. – MrTuttle Mar 06 '12 at 22:37
  • 1
    It really couldn't hurt to mention SNI. – Shane Madden Mar 06 '12 at 22:40
  • 1
    @MrTuttle oops. I have added those points, I guess it turned into a monster answer when I started added stuff that I thought was useful... ;-) – Tom Mar 06 '12 at 22:44
  • @ShaneMadden haha, well you might as well go and read the wikipedia article if you want that.. – Tom Mar 06 '12 at 22:45
  • So, I must have two public IP addresses? In your example, SSL is enabled for both VirtualHosts. In my given scenario, I only need SSL on one… I don't know if that makes any difference. – Oliver Joseph Ash Mar 06 '12 at 22:49
  • @OliverJosephAsh ask your ISP or host to assign another public IP address for the second SSL virtualhost. As MrTuttle and Shane said, you could look into wildcard SSL certs and SNI, but I didn't realise either of those was more than a RFC curiosity... – Tom Mar 06 '12 at 22:49
  • @TomH I mention it here because you're stating in pretty absolute terms that the server can never know what the client's requesting before serving data.. which, as mentioned, is not true when a wildcard or SAN cert is used - and it's *really* not true when the client supports the decade-old SNI extension (which pretty much all modern clients do; Windows XP is the lone holdup to widespread deployment). – Shane Madden Mar 06 '12 at 22:52
  • I was having a play around and I've got it to work this way - without another public IP address. Is this okay? http://hastebin.com/nujorukide.apache – Oliver Joseph Ash Mar 06 '12 at 23:01
  • TLS overcomes those limitations with SNI in particular. And yes, I know that SSL is oft used to also mean TLS. But I think especially because of that TLS and SNI should have been mentioned. In times of limited IPv4 addresses. Side-note: only very new `mod_ssl` and `mod_gnutls` can handle SNI, AFAIK. – 0xC0000022L Mar 06 '12 at 23:03
  • @OliverJosephAsh sure, buts thats just the 1 SSL site on the default IP – Tom Mar 06 '12 at 23:05
  • This works - 2 normal sites, SSL on one. Is this the best way to resolve my original question? http://hastebin.com/suyigapeyu.apache – Oliver Joseph Ash Mar 06 '12 at 23:09
  • @OliverJosephAsh in your original question you also wanted https://oliverash.me to be available by SSL, but you would have to use the SNI or mod_gnutls (http://www.outoforder.cc/projects/apache/mod_gnutls/) solutions to get the second one recnognised. – Tom Mar 06 '12 at 23:20
  • @ShaneMadden you can tell I learned my trade in the early days of 200x because I am well out of date. ;-) Its says no support for SNI on xp any versions, but presumably firefox and chrome on xp works fine with SNI. (http://en.wikipedia.org/wiki/Server_Name_Indication#Support) – Tom Mar 06 '12 at 23:27
  • @TomH Sorry for the misunderstanding but I only wanted one domain to be available by SSL (in this case `songtagapp.com`). – Oliver Joseph Ash Mar 06 '12 at 23:38
  • @OliverJosephAsh in that case, your pastebin is correct, and my answer is wildly tangential. However I have learned all about SNI which seems quite interesting – Tom Mar 06 '12 at 23:48
  • Thank you! Is my pastebin completely correct? I have all of this inline in my `httpd.conf` file. Not sure if that is a best practice. I like to follow best practices :P But thank you for your help, your answer helped me to understand, and made me aware of just how amateur I am at all of this… – Oliver Joseph Ash Mar 06 '12 at 23:53
  • one thing about your [pastebin](http://hastebin.com/suyigapeyu.apache) is that ServerAlias is redundant in SSL virtualhosts, because the IP is used to identify which config to use. Hence if your certificate is `www.mybadger.com` then any SSL requests like `https://mybadger.com` will produce lots of SSL warning messages to the client browser because mybadger.com is NOT www.mybadger.com (note the missing www). If your cert is www.mybadger.com, then your ServerName should also be www.mybadger.com – Tom Mar 07 '12 at 00:00
  • Re: inline virtualHosts declarations, its definitely neater to break each vhost into its own file under /etc/httpd/conf.d/www.mymonkey.com.conf In addition, leaving the httpd.conf pristine, also allows that file to be updated by yum or apt during httpd upgrade, however most "power" users would make edits to httpd.conf anyway. ie in summary put your vhosts in their own files under /etc/httpd/conf.d/www.mysite.com.conf if you can muster the motivation... ;-) (and use prefixes like 1www.mysite.com.conf to control the order of vhost loading by httpd) – Tom Mar 07 '12 at 00:12
  • @TomH Fair enough! Firefox yes, Chrome no - on Windows it uses the same Microsoft crypto libraries as IE, so it has the same limitations. – Shane Madden Mar 07 '12 at 00:38
1

Your ServerAlias for www is perfectly normal; no worries. If you want to get fancy, you can setup a RewriteRule to direct traffic from www.example.com to example.com, or vice-versa. As for SSL support, use separate VirtualHost definitions for your :80 and :443 virtual hosts.

MrTuttle
  • 1,176
  • 5
  • 5