Nginx ssl proxy to multiple apache servers

apache-2.2nginxsslsubdomain

I have multiple nodejs web application servers over HTTP and I need to certify the requests sent to those servers. I was thinking about using nginx as a proxy for the requests, certifying only the nginx server with an SSL certificate so that data/images sent back to the client are served over HTTPS.

This is the structure I thought about:

                                   +--- app1 ---> node.js on ip:10001
                                   |
client --> https --> nginx --> http --- app2 ---> node.js on ip:10002
                                   |
                                   +--- app3 ---> node.js on ip:10003

My concern is about the response object from the proxied request. Webkit based browsers and Safari are warning me that my application is in HTTPS but serving content over HTTP (mixed content warning).

By certifying the proxy server, would my response to the client be validated as HTTPS or as HTTP?

My nginx proxy would have a certified subdomain like proxy.domain.com, so requests would be done, as an example, like "https://proxy.domain.com:10001". The request is done over HTTPS to the proxy, but the returned server content is over HTTP. How would the proxy enact on such returned contents?

Would it apply SSL encryption, hence sending back the resource like so: "https://proxy.domain.com:10001/resource.png"

Thanks in advance everyone

Best Answer

what you are trying is named as SSL termination. It is when the reverse proxy handles the SSL then forward the request to proxied server with HTTP protocol. So the client will have HTTPS connection but from reverse proxy (nginx) to proxied server(apache) will have HTTP connection. In nginx you do as follow :

server {
    listen              443 ssl;
    server_name         www.example.com;
    ssl_certificate     www.example.com.chained.crt;
    ssl_certificate_key www.example.com.key;

    location /{
        proxy_pass http://upstream_name:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Scheme $scheme;
    }
}

If you want to study it more you can use this official documentation from Nginx https://www.nginx.com/resources/admin-guide/nginx-ssl-termination/. For mixed content, I think I have same though to @Bert. It's maybe because in the HTML you still serving http protocol.

Related Solutions

Nginx – Proxy HTTPS requests to a HTTP backend with NGINX

The type of proxy you are trying to set up is called a reverse proxy. A quick search for reverse proxy nginx got me this page:

http://intranation.com/entries/2008/09/using-nginx-reverse-proxy/

In addition to adding some useful features like an X-Forwarded-For header (which will give your app visibility into the actual source IP), it specifically does:

proxy_redirect off

Good luck! :)

Nginx reverse proxy – try upstream A, then B, then A again

Key points:

Don't bother with upstream blocks for failover, if pinging one server will bring another one up - there's no way to tell nginx (at least, not the FOSS version) that the first server is up again. nginx will try the servers in order on the first request, but not follow-up requests, despite any backup, weight or fail_timeout settings.
You must enable recursive_error_pages when implementing failover using error_page and named locations.
Enable proxy_intercept_errors to handle error codes sent from the upstream server.
The = syntax (e.g. error_page 502 = @handle_502;) is required to correctly handle error codes in the named location. If = is not used, nginx will use the error code from the previous block.

Here is a summary:

server {
    listen ...;
    server_name $DOMAINS;

    recursive_error_pages on;

    # First, try "Upstream A"
    location / {
        error_page 418 = @backend;
        return 418;
    }

    # Define "Upstream A"
    location @backend {
        proxy_pass http://$IP:81;
        proxy_set_header  X-Real-IP     $remote_addr;
        # Add your proxy_* options here
    }

    # On error, go to "Upstream B"
    error_page 502 @handle_502;

    # Fallback static error page, in case "Upstream B" fails
    root /home/nginx/www;
    location = /_static_error.html {
        internal;
    }

    # Define "Upstream B"
    location @handle_502 { # What to do when the backend server is not up
        proxy_pass ...;
        # Add your proxy_* options here
        proxy_intercept_errors on;          # Look at the error codes returned from "Upstream B"
        error_page 502 /_static_error.html; # Fallback to error page if "Upstream B" is down
        error_page 451 = @backend;          # Try "Upstream A" again
    }
}

Original answer / research log follow:

Here's a ~~better~~ workaround I found, which is an improvement since it doesn't require a client redirect:

upstream aba {
    server $BACKEND-IP;
    server 127.0.0.1:82 backup;
    server $BACKEND-IP  backup;
}

...

location / {
    proxy_pass http://aba;
    proxy_next_upstream error http_502;
}

Then, just get the control server to return 502 on "success" and hope that code is never returned by backends.

Update: nginx keeps marking the first entry in the upstream block as down, so it does not try the servers in order on successive requests. I've tried adding weight=1000000000 fail_timeout=1 to the first entry with no effect. So far I have not found any solution which does not involve a client redirect.

Edit: One more thing I wish I knew - to get the error status from the error_page handler, use this syntax: error_page 502 = @handle_502; - that equals sign will cause nginx to get the error status from the handler.

Edit: And I got it working! In addition to the error_page fix above, all that was needed was enabling recursive_error_pages!

Best Answer

Related Solutions

Nginx – Proxy HTTPS requests to a HTTP backend with NGINX

Nginx reverse proxy – try upstream A, then B, then A again

Related Topic