You are not logged in.
I maintain a small private Arch server which I use to serve up a personal website and serve websites for a couple of friends as well. Currently, I do this with name based virtual hosting, but I would like to be able to secure each of these sites with their own SSL certificates. I understand that I can do this by switching over to IP based virtual hosting and using IP aliases, but what I'm struggling with is the best way to securely deliver HTTPS requests to those virtual hosts.
The option I've been exploring the most extensively is the apache reverse proxy, but it seems to present challenges to ensuring separate, secure, SSL connections between each host and its clients that make me think I should start looking elsewhere (e.g., anyone connecting to any of the websites would be sharing the same encrypted pipeline since they connect to the same proxy).
The option I've started looking at since is using Apache's redirect rules to redirect a request to it's appropriate IP based virtual host. However, the challenge here seems to be that redirect rules don't appear to be intended to reroute a request coming from outside of the subnet to a different subnet IP address.
I've considered exploring the option of setting up a DNS name server and setting up my DNS records to point to it, but this would mean I have a lot of reading ahead of me, and a whole mess of time to invest in setting it up. Obviously, I'd prefer to be able to play with a few config files to make it work.
Am I even on the right track? Can anyone comment on these possible solutions or point me in the direction of a better one?
Offline
You could use VirtualHosts of different names to direct to different document roots. It's actually really easy:
<VirtualHost thisdomain.com:80>
...
</VirtualHost>
<VirtualHost thatdomain.com:80>
...
</VirtualHost>Apache will look at the URL used to access the server and serve the appropriate content. Different domain names, different content, same IP. For SSL, you'd do the same, but put your SSL configuration specific to each host (cert, key, etc.) in blocks that look like <VirtualHost thisdomain.com:443>.
Last edited by synthead (2012-08-30 20:04:26)
Offline
As I stated in my OP, I'm already using the name based virtual hosting you're suggesting. Unfortunately, according to the Apache wiki, what you're suggesting in relation to dealing with SSL certs is not possible. The only way for name based virtual hosts to all be fully ssl capable is to share an SSL certificate, which is only desirable (or even viable) if the separate virtual hosts are under the same domain.
Offline
It would mean changing web servers, but Nginx would be able to accommodate different SSL certs for different virtual hosts.
http {
server {
server_name domain.number.one;
listen 443;
ssl on;
ssl_certificate /path/to/cert1.pem;
ssl_certificate_key /path/to/cert1.key;
...
}
server {
server_name domain.number.two;
listen 443;
ssl on;
ssl_certificate /path/to/cert2.pem;
ssl_certificate_key /path/to/cert2.key;
...
}
}If you're dead set on using Apache, you might be able to set up Nginx in front of Apache, and still let nginx handle the SSL portion.
Last edited by Morrad (2012-08-30 20:58:54)
Offline
You could use VirtualHosts of different names to direct to different document roots. It's actually really easy:
<VirtualHost thisdomain.com:80> ... </VirtualHost> <VirtualHost thatdomain.com:80> ... </VirtualHost>Apache will look at the URL used to access the server and serve the appropriate content. Different domain names, different content, same IP. For SSL, you'd do the same, but put your SSL configuration specific to each host (cert, key, etc.) in blocks that look like <VirtualHost thisdomain.com:443>.
I have to apologize for jumping the gun on you, as it turns out you were 100% correct. Mor research yielded my answer, being that modern browsers and apache versions 2.2 and up do support ssl with name based virtual hosts through SNI
Offline