I’ve been looking into this because I did not want to spend more money on extra IP addresses for SSL connects. But I do have several websites I want to access encrypted (that is .. not over plain HTTP).

There definitely are some articles (and forum threads) out there that come close, but this is how it’s done 🙂

Some predefs

The goal is to be able to connect to multiple VirtualHost’s on an Apache webserver.

We have a localpc behind a NAT-ed internet connection (yourpc.locality.lan) and the aforementioned publicly accessible webserver on the net somewhere (yourserver.example.com).

I’m assuming you can already connect to your server via SSH, based on a pub/priv keypair.

Local to remote

There are some things that need to be set local AND remote to make sure that Apache knows to which (not publicly accessible) VirtualHost it must redirect your HTTP request. That is, make up a name and put it in your /etc/hosts file and have it resolve to 127.0.0.1. E.g:

Important! You need to put the ‘mysuperadminsite’  entry in your /etc/hosts file on your server as well. Otherwise it won’t work because Apache can’t figure out where this needs to go (more on apache config in a sec).

Then, the actual SSH tunnel command is this:

There are ofcourse nicer ways to fully hide/automate the SSH tunnel, but by doing it manually like this you are explicitly remembered that you’re in ‘admin-mode’ 🙂

Apache trickery

Ok, so how does Apache know where to go when your HTTP request hits the server side? As your mysuperadminsite request is resolved to 127.0.0.1 (on the server), apache needs this as a NameVirtualHost. So put this in your global Apache config somewhere.

Then you create an apache VirtualHost config with a setup like this.

And so, apache resolves the request to 127.0.0.1 where, based on the X-Header (containing the mysuperadminsite name) sent by your browser, it actually finds a vhost to handle your request.

This is a very safe way to handle your secure access because the VirtualHost is only handled by apache when it comes in on your loopback interface. Moreover FQDN’s based on “locality.lan” are not resolvable in the outside world.

It does however require a second website instance. You could combine an externally accesible VirtualHost by starting your config with this.

This way you don’t have to have a second VirtualHost config (and thus website instance) for management. But it’s easier to overlook going secure and thus have your passwords or whatever sniffed.

Gotcha’s

None that I know of, but feel free to point them out 🙂

Safe computing!