Howto: Using Nginx to Load Balance Servers Part 2

Adding free, LetsEncrypt SSL certificates to your server is easy to do, has no recurring costs and protects against man in the middle attacks. LetsEncrypt uses the ACME (Automated Certificate Management Environment) protocol that ties a certificate to a DNS domain and a website, so expired certificates can be a thing of the past. There are no good reasons I can think of for not using SSL for all websites now.

Whereas the previous article assumed you were only using your Nginx server to proxy or load balance your witness websocket server, this article describes a superior configuration that includes virtual server files which support an SSL protected websocket proxy, load balancing, secure bts_tools web hosting and acme challenge response to handle LetsEncrypt SSL certificate renewals on non-SSL port 80.

Here are the relevant links to my github repository, previous article and @jesta's original article. You will also need to download and install the getssl bash script that implements the acme-challenge protocol for the certificates. It has few requirements being a bash script, but it does require curl and nslookup. On Debian or Ubuntu nslookup is provided in the dnsutils package if it's not already installed.

Complete instructions for using the getssl script can be found on its github repo I linked above. There are three items to setup:
1) Configuration files (2) for the script to describe the domains to obtain certificates for
2) Nginix configuration required for acme-challenges
3) Crontab entry to run the script to renew certificates

The certificate management setup is mostly separate and autonomous to the Nginx configuration. Definition for the /.well-known/acme-challenge is already provided in the two ssl_server* scripts in my github repo. I recommend getting Nginx setup first so it can serve files from the /.well-known/acme-challenge/ folder and then install the getssl script to get your SSL certificates. If you want to run an SSL protected bts_tools interface alongside your proxied websocket witness node you will need to have a separate domain name for it so the server can distinguish which virtual server (websocket or bts_tools) requests should be routed to, since they both use standard SSL port 433. You can avoid the additional domain name if you want to run them on different ports. Your choice.

The **ssl_server_lb.conf** file is used to define the load balancer server that dispatches requests to a pool of SSL websocket servers (wss://...). It also provides separate, non-load balanced virtual servers to proxy a local websocket server, bts_tools and the acme-challenge server on port 80.

If you run a witness node on the load balancing server that is to be included in the pool of servers to be load balanced, the local server requires a virtual server definition that responds to wss requests on a different port than the non-SSL ws witness server and the load balanced server on the standard SSL port 433. The reason for this is that the load balancer balances only SSL requests, dispatching them to an SSL websocket server. The local witness_node cannot handle the SSL encryption directly, it requires Nginx to do the decryption and pass unencrypted ws requests to it. Any unused local port can be used above 1024.

There's little more to it than that. Don't forget to update your /etc/nginx/nginx.conf with the 1 line used for the load balancer and defines the ws zone for shared memory.

Thanks again to @jesta and @reolandp for their work and recommendations. And as always thanks to you for your support!