CustomerID High Availability CustomerID SSL On Linux

There are three ways to configure SSL.

1. Front-End Terminated SSL
   1. Drawbacks: 
      1. If an untrusted party penetrates the internal network/DMZ the traffic is susceptible to eavesdropping
2. SSL Pass-Through
   1. Drawbacks: 
      1. Setting the sticky-bit on the reverse proxy may prove impossible and this may preclude additional reverse proxy functionality .
      2. You will not be able to set headers, such as X-Forwarded-For, so you will lose the clients' IP address information.
3. Front-End Terminated SSL With Back-End SSL
   
   1. This is the recommended method

In a cluster like this example below:

In the different configuration modes, SSL Certificates would be configured as shown in the following table

Terminate SSL to the Reverse Proxy

If you decide to leave the Back-End traffic unsecured, there's nothing to do in respect to WildFly configuration, just configure your Reverse Proxy accordingly.

Generally about SSL on Back-End Servers

The process of configuring SSL on the Back-End server nodes is two phased:

1. Put a server certificate in a keystore
2. Register keystore to WildFly

For the first phase we have provided scripts that will generate self-signed certificates, which can be used for only testing purposes but should be avoided in production. 

Pass-Through SSL

Run the config-wildfly-domain-cert-backend.cmd script on the master node, then copy the generated keystore.pfx file over to the slave node to the same path. The keystore.pfx file will be generated in the path ${WILDFLY_HOME}\domain\configuration\keystore.pfx.

cd /usr/local/ubisecure/customerid/tools
./config-wildfly-domain-cert-backend.sh
scp /usr/local/wildfly-10.1.0.Final/domain/configuration/keystore.pfx {user}@{host}:/usr/local/wildfly-10.1.0.Final/domain/configuration/keystore.pfx

Encrypt traffic separately between Front-End and Back-End servers.

These scripts will generate self-signed SSL certificates that uses each host's IP address in the cn-field.

On the Master Node, run config-wildfly-domain-cert-master.sh

cd /usr/local/ubisecure/customerid/tools
./config-wildfly-domain-cert-master.sh

On the Slave Node, run config-wldfly-domain-cert-slave.sh

cd /usr/local/ubisecure/customerid/tools
./config-wildfly-domain-cert-slave.sh

In this configuration - and depending on your Front-End Server - you may have to separately configure your Front-End Server(s) to trust the Back-End servers' certificates.

Register keystore file to WildFly

In the second phase, when you have produced the key store file, you can configure the HTTPS sockets on WildFly by using the following script on the master node. The script expects to find a keystore.pfx file in the path "${WILDFLY_HOME}\domain\configuration\keystore.pfx". The script will configure key store access using the password that was defined in win32.config before setup.cmd was run

cd /usr/local/ubisecure/customerid/tools
./config-wildfly-domain-https.sh