Web Server Hostname-based request "Forwarding"

[b4u]

Hi,

I'm starting up a small home server for some web applications, and I would like to know how to work out the hostname to diferent context or even application servers.

Let me explain with an example:

I have mydomain.com, and 2 DNS hostnames defined:

app1.mydomain.com
app2.mydomain.com

Now they both land on the server, on port 80.

In the server, with say an internal IP address of 192.168.1.1, I'll have JBoss 5.1.0 running on 8080. I may even have a Tomcat running on 8081.

What I need:

For http://app1.mydomain.com/ I want it to land on http://192.168.1.1:8080/myapp1

And http://app2.mydomain.com/ I want it to land on http://192.168.1.1:8080/myapp2

So they are diferent web applications running on the same JBoss instance, and I want the user to just know the simple app?.mydomain.com address, and the server will pick it from here.

In the future I want the possibility for an http://app3.mydomain.com/ the will point to http://192.168.1.1:8081/myapp3 that is a web app running on a diferent web container, for example a Tomcat listening on 8081 port, side-by-side in the same machine running JBoss on port 8080.

So my guess is ... I need Apache Web Server? And configure VirtualHost and/or Proxy?

I'm struggling a bit through the documentation ... a little light would help alot. I'm having dificulty filtering the examples I found to what really fits my purposes.


Thanks.

 

[Cogman]

The term you are looking for is "subdomain" It is a pretty common feature so having the term should really help you in finding what you need.

Here is a page that describes how to do it in apache and IIS.
http://content.websitegear.com/article/subdomain_setup.htm

 

[Crusty]

Apache, VirtualHosts and a proxy are exactly what you need.

Apache can handle both domains on the same port/ip with ease if it is configured properly. Note that you can never have SSL with pure name based virtual hosting.

Apache also has a module called mod_proxy that can use to configure apache as a reverse proxy. You simply configure the VirtualHost like normal, but instead of having some location or directory directives you put the reverse proxy configuration there. So you could have each virtualhost proxy to a different application server.

Mod proxy is very configurable and works quite well, but if you are looking for a dedicated reverse proxy service HAProxy is very fast. Nginx can also be configured as a reverse proxy.

 

[b4u]

Thanks for the links and info about other software. I'll check them all, as I really want to get this up and running.

Note that you can never have SSL with pure name based virtual hosting.

I've already read something about that ... what does it mean? If I use Apache I can never have webapps with SSL at all? No https at all?

And the other proxy software, HAProxy, Nginx, will they allow it?

I have only http requests, but latter I will add some SSL for securing one of them ...

Thanks

 

[Crusty]

Thanks for the links and info about other software. I'll check them all, as I really want to get this up and running.



I've already read something about that ... what does it mean? If I use Apache I can never have webapps with SSL at all? No https at all?

And the other proxy software, HAProxy, Nginx, will they allow it?

I have only http requests, but latter I will add some SSL for securing one of them ...

Thanks

No, SSL simply operates at a different layer than HTTP traffic. In order to use SSL with a domain name that domain name has to be the only name using that IP address.
It's not a flaw in any of the servers, it's just simply how SSL operates when combined with HTTP over the network.

Simply put, if you encrypt your HTTP request and send it to the server the only thing it knows about the request upon arrival are the source and destination ip/port pairs, nearly everything else is encrypted. In order to know how which website the request belongs to the server needs to read some data out of the encrypted HTTP packet, mainly the Host header.

Since this data is encrypted it needs to use the right certificate to decrypt the data, but certificates are identified by the website name they are securing. So in order for the web server to properly handle the request it needs to be able to read encrypted data without knowing what certificate to use(based on the request). For example, if you had two websites running on 1.1.1.1:80 both using SSL, how does the server know which of the two website's certificates to use to decrypt the packet? The only information it has that tells it that is encrypted! Therefore, any hostname using SSL must use their own IP and port combination so that when an encrypted packet arrives the server can blindly decrypt it using the correct certificate.

This is where the server configuration comes in, you simply tell apache to use a specific certificate file for a specific site and make sure it's the only one listening on the IP and port. It's the unique combination of port/IP that allows apache to use the right certificate file.

It should be noted that https sites usually operate on port 443 so you will have no issue running a single http and a single https site off of one IP address.

 

[b4u]

No, SSL simply operates at a different layer than HTTP traffic. In order to use SSL with a domain name that domain name has to be the only name using that IP address.
It's not a flaw in any of the servers, it's just simply how SSL operates when combined with HTTP over the network.

Simply put, if you encrypt your HTTP request and send it to the server the only thing it knows about the request upon arrival are the source and destination ip/port pairs, nearly everything else is encrypted. In order to know how which website the request belongs to the server needs to read some data out of the encrypted HTTP packet, mainly the Host header.

Since this data is encrypted it needs to use the right certificate to decrypt the data, but certificates are identified by the website name they are securing. So in order for the web server to properly handle the request it needs to be able to read encrypted data without knowing what certificate to use(based on the request). For example, if you had two websites running on 1.1.1.1:80 both using SSL, how does the server know which of the two website's certificates to use to decrypt the packet? The only information it has that tells it that is encrypted! Therefore, any hostname using SSL must use their own IP and port combination so that when an encrypted packet arrives the server can blindly decrypt it using the correct certificate.

This is where the server configuration comes in, you simply tell apache to use a specific certificate file for a specific site and make sure it's the only one listening on the IP and port. It's the unique combination of port/IP that allows apache to use the right certificate file.

It should be noted that https sites usually operate on port 443 so you will have no issue running a single http and a single https site off of one IP address.

Wow, thanks for the explanation. I see I'm missing some basic knowledge about the subject.


1. About ports, the http port is 80, if I put http://something on the browser, it will go through port 80, but if I put https://something it will go through 443, correct? So http://something:443 should not work because the browser ignores the SSL protocol if not httpS?

2. So if I have one web server, with 2 SSL sites and one regular HTTP one, since they use the same IP/port, I can only have 1 SSL certificate installed?

3. If I want to have 2 different certificates, one for each site, I must create another application server instance, running on a different port (same IP) to apply a diferent SSL certificate?

4. The SSL certificates must be installed on the web servers, correct? And if I use Apache HTTP for subdomain resolution, I must also reference them there two? To point out that for example ssl1.mydomain.com should work with certificate A and ssl2.mydomain.com should work with certificate B (and then point them to the same IP but each for a different port)?

Sorry this basic questions ... I find many info around the web about SSL, but most gives an explanation of the SSL protocol and the like ... not how this all works together.

Thanks

 

[Crusty]

Wow, thanks for the explanation. I see I'm missing some basic knowledge about the subject.


1. About ports, the http port is 80, if I put http://something on the browser, it will go through port 80, but if I put https://something it will go through 443, correct? So http://something:443 should not work because the browser ignores the SSL protocol if not httpS?

Correct. by specifying either http or https and talking to the other type(http in browser, https on server and vice versa) you'll get all sorts of error messages that won't make sense.

2. So if I have one web server, with 2 SSL sites and one regular HTTP one, since they use the same IP/port, I can only have 1 SSL certificate installed?

A single server can have more than one IP address so it's definitely possible to have a single 'web server(Apache2)' hosting lots of SSL sites. For every IP address you have on the system you can run a single virtualhost in apache that uses SSL using the default port(443).

3. If I want to have 2 different certificates, one for each site, I must create another application server instance, running on a different port (same IP) to apply a diferent SSL certificate?

The file /etc/apache2/ports.conf in Debian based installs contains a list of all IP address and port combinations for apache2 to listen on. As long as you have 2 different IP addresses listed with port 443 you can run both sites with the same Apache2 install.

If you want to avoid this whole mess, but spend a bit more money, you can get a wildcard certificate that can be used for what you want. They are designed with the idea in mind that you are going to be hosting several secure sites from the same domain on the same IP address. The restrictions are that they are more expensive and they only work for a single TLD, so if you wanted to host ssl1.domainA.com and ssl2.domainB.com you would still need 2 certificates.

I highly recommend downloading and installing some visualization software and install the distro that server is running. The best way to understand this stuff is to see it in action. You can generate self-signed certificates from the command line that can be used in Apache to test out configurations. You'll get a warning in your browser because it is self-signed, but it still a good way to do a sanity check on your configuration.

4. The SSL certificates must be installed on the web servers, correct? And if I use Apache HTTP for subdomain resolution, I must also reference them there two? To point out that for example ssl1.mydomain.com should work with certificate A and ssl2.mydomain.com should work with certificate B (and then point them to the same IP but each for a different port)?

Sorry this basic questions ... I find many info around the web about SSL, but most gives an explanation of the SSL protocol and the like ... not how this all works together.
Thanks

That is pretty much it. Under each VirtualHost section you can enable the SSLEngine and specify the public and private key files to use for the virtualhost.