Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to forward SSL requests depending on the hostname to sub daemons running on my machine. To achieve such a behaviour, I tried experimenting with nginx, which will then act as a reverse proxy / router.

My config file:

# ...
location / {
    proxy_set_header Host $http_host;

    if ($host = '') { proxy_pass; }
    if ($host = '') { proxy_pass; }
    if ($host = '') { proxy_pass; }
    if ($host = '') { proxy_pass; }
    if ($host = '') { proxy_pass; }
    if ($host = '') { proxy_pass; }
    if ($host = '') { proxy_pass; }
    if ($host = '') { proxy_pass; }
    # ... 

However, due to the nature of SSL, the host is encrypted as well. When trying to request a url, I am getting OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol. Letting one of the daemons listen to port 443 works fine.

Is it possible to use nginx for this kind of setup? If no, is there a tool for achieving this behaviour?

Each sub-service is using a own SSL certificate. One idea would be to use unique machines for each service and let them listen to 443 itself, but that's what I'm trying to avoid.

Any ideas on this?

share|improve this question
up vote 2 down vote accepted

Is it possible to use nginx for this kind of setup? If no, is there a tool for achieving this behaviour?

As you have already noted, your reverse proxy knows nothing about the URI or the HTTP headers as this information is enclosed and encrypted within the TLS protocol. Name-based virtual hosts would not work out with TLS that easily.

The only notable exception to this rule is the Server Name Indication extension to TLS, but this would need support on the server as well as all potential clients. NGNIX supports SNI on the server side, but I suppose it still would need to terminate the TLS connections for your application. HAproxy would be able to do a backend decision based on the SNI-supplied hostname without terminating the tunnel - maybe you want to look into that.

If you could lay your hands on a single certificate which would carry all of hostname*.example*.com´ combinations as SAN attributes, you could set up NGNIX with this certificate to terminate all tunnels, inspect the headers and pass on the traffic depending on the values as a reverse proxy. This kind of solution has the chance of being supported by more potential clients, but has the obvious downside that the certificate needs to be re-issued every time you need to add or remove a host name from the list.

share|improve this answer
Good point about the SNI, but is this actually usable for routing and not just for SSL certificate distribution? A UCC certificate probably wouldn't work as no authority would authorise domains in the SAN that are now owned by me. – dvcrn Jun 23 '13 at 10:46
@Dabido SNI is not about distribution - it allows the client to transmit the desired host name in clear as part of the TLS handshake so the server would be able to make a decision based on this. I've added some clarifications to the answer, take a look if this is of some use. – the-wabbit Jun 23 '13 at 19:46
Bullseye! HAProxy is indeed capable of SSL routing without terminating the tunnel. My first test is running like a good oiled engine. Kudos to you for this tip! – dvcrn Jun 24 '13 at 4:00
@Dabido welcome you are. – the-wabbit Jun 24 '13 at 15:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.