Over the years, there are many Oracle E-Business WMS and MSCA customers who are looking to enhance the security of communication between the mobile MWA users and Oracle MWA server. As we know, the MWA server used in MSCA and WMS natively runs in Telnet protocol where all data including username and password are sent in clear text. One of the ways to secure the communication is to encrypt the data between client and server and this can be done using SSL (Secure Sockets Layer).
In recent update, Oracle added SSL support in MWA server. However SSL is not supported by MWA Dispatcher, confirmed in “Does MWA Dispatcher (MWADIS) Accept SSL or TLS Connections? (Doc ID 2175344.1)”. This is unfortunate as many customers are using MWA dispatcher to load balance their MWA users. In such case, to make SSL work customer has to either connect the device directly to MWA port or use other types of load balancer which supports SSL passthrough.
This document is written to help customers in two regards. First, it describes steps to enable SSL in Oracle MWA server. For reference, please read information in note “Oracle Mobile Supply Chain Applications for Oracle E-Business Suite Release Notes (Doc ID 2108155.1)” to enable SSL in standard Oracle MWA server. Second, it introduces a high performing popular software load balancer called haproxy and show how to use it to load balance multiple MWA ports running in SSL mode.
The high level steps are as follows:
- Generate an SSL certificate, we can either get this from a trusted provider (paid) or we can generate a self-signed certificate (free)
- Configure mwa.cfg to enable the SSL
- Restart MWA service
- Install and configure haproxy
To generate a self-signed SSL certificate using the keytool command on Oracle EBS application node:
- Open a command prompt or terminal
- Run this command
keytool -genkey -keyalg RSA -alias tomcat -keystore mwassl.jks -validity <days> -keysize 2048
Where <days> indicate the number of days for which the certificate will be valid.
- Enter a password for the keystore. Note this password as you require this for configuring the server
- When prompted for a first name and the last name, press Enter to keep it blank.
- Enter the other details, such as Organizational Unit, Organization, City, State, and Country
- Confirm that the information entered is correct
- When prompted with “Enter key” password for <mwassl>, press Enter to use the same password as the keystore password
- Run this command to verify the contents of the keystore
keytool -list -v -keystore mwassl.jks
- When prompted, enter the keystore password note in Step 3. The basic information about the generated certificate is displayed. Verify that the “Owner” and “Issuer” are the same. Also, you should see the information you provided in Step 5 and 6.
The certificate is now complete and ready to use. Move this file to $INST_TOP/admin/install. If you run in 12.2.X, please move to both RUN and PATCH.
Screenshot of how we generate a self-signed certificate.
Screenshot of how we verify the self-signed certificate.
Next, we edit $INST_TOP/admin/install/mwa.cfg file to enable the SSL. For 12.2.X, please update for both RUN and PATCH. In the file, there are four properties related to SSL.
mwa.Security.SSLSocket=TRUE mwa.Security.KeyStore=mwassl.jks mwa.Security.KeyStorePassword=mwasslpassword mwa.Security.Protocols=TLSv1 mwa.Security.CipherSuites=SSL_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
The mwa.Security.KeyStore should be filename of the SSL certificate we generated earlier, and mwa.Security.KeyStorePassword should be the password we use when generating the certificate.
Once done, restart the MWA services and now we have MWA server running in secure SSL!
Please note that once MWA server runs in SSL mode, we can no longer use non-secure MWA client, like telnet client, to connect. We have to use MWA client that supports SSL mode to connect to the server. One such client is Intellinum Express Client, a native GUI client that supports SSL, available for Android, Windows CE/Mobile and Windows PC.
As mentioned earlier, once we enable SSL, we can’t use MWA dispatcher anymore as it does not decrypt/encrype SSL data. One good option that we have tested to work with Oracle MWA server or our Intellinum Express Server is haproxy load balancer (www.haproxy.org). This is a high performing and reliable TCP/HTTP software load balancer used by many large organizations in the world.
There are many good resources in the Internet on how to install and configure haproxy. Once installed and started, we can verify haproxy is running by using command:
sudo service haproxy status
Similar to MWA which has configuration file mwa.cfg, haproxy has a configuration file haproxy.cfg. The default location is /etc/haproxy/haproxy.cfg. For reference, we have shown below a sample haproxy.cfg which runs the load balancer on port 10860 (think of this like MWA dispatcher port) and load balances to 3 MWA ports running on 192.168.1.232 port 10200, 10202, 10204 respectively.
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 defaults log global mode tcp timeout connect 30s timeout client 1h timeout server 1h option tcplog frontend mwaproxy mode tcp bind *:10860 default_backend mymwaservers backend mymwaservers mode tcp server mwa1 192.168.1.232:10200 check server mwa2 192.168.1.232:10202 check server mwa3 192.168.1.232:10204 check stick-table type ip size 1m expire 30m stick on src option redispatch
The important relevant sections in haproxy.cfg are the frontend and backend. The frontend has the port it should listen for incoming connection and the backend lists all the mwa ports we want to load balance. The stick-table and stick are used for sticky session so in case a client gets disconnected from server (due to WiFi interruption for example), the client can be forwarded to the same server it was connected before the disconnection.
Notice that we do not do anything special to implement TLS passthrough. It’s enough to pass the traffic to the backend servers and let them handle the encryption and decryption. That’s all there is to TLS passthrough.
Don’t forget to restart haproxy after any changes in haproxy.cfg with the following command:
sudo service haproxy restart
Now we can connect MWA client to host/port where haproxy is running and it should forward the connection to MWA server. We have verified that all features in Intellinum Express Server such as transaction personalization, voice interface, e-signature and quick reconnect are working in SSL stand alone or SSL with haproxy.
Hope this article has been useful for you. If there is any questions on this article, or you would like to try our products Express Client or Express Server, feel free to reach out to [email protected].