Two node CustomerID SSL on Linux - CustomerID
Introduction
There are three optional ways to configure SSL.
- Front-End Terminated SSL
- Drawbacks:
- If an untrusted party penetrates the internal network/DMZ the traffic is susceptible to eavesdropping
- Drawbacks:
- SSL Pass-Through
- Drawbacks:
- Setting the sticky-bit on the reverse proxy may prove impossible and this may preclude additional reverse proxy functionality .
- You will not be able to set headers, such as X-Forwarded-For, so you will lose the clients' IP address information.
- Drawbacks:
- Front-End Terminated SSL With Back-End SSL
- This is the recommended method
In a cluster like this example below:
FQDN | Internal IP | External IP | Port | |
---|---|---|---|---|
Front-End | account.mydomain.com | 10.0.0.1 | 90.100.110.120 | 443 |
Back-End Node 1 | back-end-1.mydomain.com | 10.1.0.1 | <none> | 7080 and 7443 |
Back-End Node 2 | back-end-2.mydomain.com | 10.1.0.2 | <none> | 7080 and 7443 |
In the different configuration modes, SSL Certificates would be configured as shown in the following table
Front-End Terminated SSL | SSL Pass-Through | Front-End Terminated SSL With Back-End SSL | |
---|---|---|---|
Front-End Certificate DN | cn=account.mydomain.com | <no SSL certificate> | cn=account.mydomain.com |
Back-End Node 1 Certificate DN | <no SSL certificate> | cn=account.mydomain.com | cn=back-end-1.mydomain.com |
Back-End Node 2 Certificate DN | <no SSL certificate> | cn=account.mydomain.com | cn=back-end-2.mydomain.com |
Steps
Unencrypted back-end
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.
Encrypted back-end
The process of configuring SSL on the Back-End server nodes is two phased:
- Put a server certificate in a keystore
- 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.
Option 1: (recommended) 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.
Option 2: Pass-Through SSL
Run the config-wildfly-domain-cert-backend.sh 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-x.x.x.Final/domain/configuration/keystore.pfx {user}@{host}:/usr/local/wildfly-x.x.x.Final/domain/configuration/keystore.pfx
Register keystore to WildFly
Keystore (default location: ${WILDFLY_HOME}/domain/configuration/keystore.pfx
) is registered to WildFly in the next step of the main installation/upgrade process: two node master/slave WildFly configuration
Securing other Back-End connections
Ubisecure CustomerID can be configured to make calls to third-party software during the user registration workflows. Typically data entered by the user is verified against a CRM or other backend service to determine which access rights a user should be automatically given based on an existing service agreement.
If you plan to use back channel connections from Ubisecure CustomerID over SSL encrypted connections, you will have to add each server's public key to the Server's cacerts file. You can find the cacerts file under ${JAVA_HOME}/lib/security/cacerts
. Once you have downloaded the server's public key, you can add it to the key store with the following commands:
${JAVA_HOME}/bin/keytool -importcert -trustcacerts -alias "<descriptive alias here>" -cacerts -storepass changeit -file /path/to/certificate.cer
These commands can also be run at a later stage when third-party backend services are added to user registration workflows.
This web page (including any attachments) may contain confidential, proprietary, or privileged information – not for disclosure without authorization from Ubisecure Inc. Copyright © 2024. All Rights Reserved.