Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space IDS and version 8.2

There are three ways to configure SSL.

...


Front-End Terminated SSLSSL Pass-ThroughFront-End Terminated SSL With Back-End SSL
Front-End Certificate DNcn=account.mydomain.com<no SSL certificate>cn=account.mydomain.com
Back-End Node 1 Certificate DN<no SSL certificate>cn=account.mydomain.comcn=back-end-1.mydomain.com
Back-End Node 2 Certificate DN<no SSL certificate>cn=account.mydomain.comcn=back-end-2.mydomain.com


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:

...

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.

Code Block
languagetextthemeRDark
cd /D %PROGRAMFILES%\ubisecure\customerid\tools
config-wildfly-domain-cert-backend.cmd

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.cmd

Code Block
theme
languagetextRDark
cd /D %PROGRAMFILES%\ubisecure\customerid\tools
config-wildfly-domain-cert-master.cmd

On the Slave node, run config-wildfly-domain-cert-slave.cmd

Code Block
languagetext
themeRDark
cd /D %PROGRAMFILES%\ubisecure\customerid\tools
config-wildfly-domain-cert-backend.cmd

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


Code Block
languagetext
themeRDark
cd /D %PROGRAMFILES%\ubisecure\customerid\tools
config-wildfly-domain-https.cmd


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 JRE's cacerts file: %JRE_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:

Code Block
languagetext
cd /D "%JRE_HOME%\lib\security\"
%JAVA_HOME%\bin\keytool -importcert -trustcacerts -alias "<descriptive alias here>" -keystore cacerts -storepass changeit -file C:\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.