cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

HAProxy SSL Passthrough configuration

Level 8

HAProxy SSL Passthrough configuration

This is going to cover one way of configuring an SSL passthrough using HAProxy.  This guide is intended to be a reference document, and administrators looking to configure an SSL passthrough should make sure the end solution meets both their company's business and security needs.

 

Why use SSL Passthrough instead of SSL Termination?

The main reason for ThingWorx would be if a company requires encrypted communication internally, as well as externally.  With SSL Termination, the request between the load balancer and the client is encrypted.  But the load balancer takes on the role to decrypt and passes that back to the server.  With SSL Passthrough, the request goes through the load balancer as is, and the decryption happens on the ThingWorx Application server.

 

What you will need to continue with this guide:

 

  • HAProxy installed
  • A working ThingWorx application server (Guide to getting one setup can be found here)
  • Tomcat configured for ssl
    • NOTE : Always contact your Security team and make sure you have a certificate that meets your business policy
    • For this tutorial, I created a self-signed certificate following along with the below guide.  If you have already obtained a valid certificate, then you can just skip over the step of creating it, and follow along with the Tomcat portion
    • Once configured, restart Tomcat and verify it is working by navigating to https://<yourServer>:<port>/Thingworx

 

With ThingWorx running as SSL and HAProxy installed, we just need to make sure the HAProxy configuration is setup to allow SSL traffic through.  We use 'mode tcp' to accomplish this.

 

On your HAProxy machine, open /etc/haproxy/haproxy.cfg for editing.  While most of this can be customized to fit your business needs, some variation of the highlighted portions below need to be included in your final configuration:

 

global

        log /dev/log    local0

        log /dev/log    local1 notice

        chroot /var/lib/haproxy

        stats socket /run/haproxy/admin.sock mode 660 level admin

        stats timeout 30s

        user haproxy

        group haproxy

        daemon

 

        # Default SSL material locations

        ca-base /etc/ssl/certs

        crt-base /etc/ssl/private

 

        # Default ciphers to use on SSL-enabled listening sockets.

        # For more information, see ciphers(1SSL). This list is from:

        #  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/

        # An alternative list with additional directives can be obtained from

        #  https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy

        ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS

        ssl-default-bind-options no-sslv3

 

defaults

        log global

         option tcplog

         mode tcp

         option http-server-close

         timeout connect 1s

         timeout client  20s

         timeout server  20s

         timeout client-fin 20s

         timeout tunnel 1h

         errorfile 400 /etc/haproxy/errors/400.http

         errorfile 403 /etc/haproxy/errors/403.http

         errorfile 408 /etc/haproxy/errors/408.http

         errorfile 500 /etc/haproxy/errors/500.http

         errorfile 502 /etc/haproxy/errors/502.http

         errorfile 503 /etc/haproxy/errors/503.http

         errorfile 504 /etc/haproxy/errors/504.http

        frontend https

         bind *:443

         mode tcp

         default_backend bk_app

 

        backend bk_app

         mode tcp

         server TWXAPP01  <twxapp01IP>:<port>

     

 

In this example, the user would connect to https://<loadbalancer>/Thingworx and the load balancer would forward the requests to https://<twxapp01IP>:<port>/Thingworx

 

That’s it!

 

A couple of side notes:

 

  • The load balancer port the clients connect to does not need to be the same as the ThingWorx port the load balancer will forward to
  • If working in a Highly Available configuration, each ThingWorx Application server needs to have its own certificate configured
  • If HAProxy seems unstable, try updating to the latest release
    • If it is on the latest release according to the Unix repository, check https://www.haproxy.org/ and see if there is a later stable release.  There have been some issues where Ubuntu's latest update in the repository is actually a few years old