Securely connect to IBM i (AS/400) from Mulesoft CloudHub

We live in an incredibly fast-paced environment. It’s hard to believe how much things have changed since the time of our first article on How to securely connect Mule to IBM i (AS/400). The world is learning to live by the new hygiene and WFH rules, the CRISPR technology is turning a human genome into a new development platform, MuleSoft has completely rebuilt the core integration runtime engine and related tooling, and my daughter just got her first post-graduation job! One thing that has remained unchanged is the requirement to communicate with the back-end applications via secure encrypted channels. In this long boring picture-less article I will provide the steps to do implement it for Mule 4 workers deployed to CloudHub.

The IBM i (AS/400) back-end TLS configuration steps remain the same since the last article. On the other hand, Mule 4 introduced several significant changes to the way we build and run the integration assets. For better or worse we no longer have access to Mule application lifetime events from Java / Sprint layer, and therefore cannot easily initialize the default SSL context to point to our custom trust store from within the Mule app.

For the on-prem runtimes, the easy solution is to import the IBM i (AS/400) certificate directly into the default certificate store (cacerts) for the JRE used by the MuleSoft runtime. However, this option is not available for the CloudHub applications since there’s no easy way to access the underlying OS on application startup. The only remaining option is to package the trust store containing the IBM i (AS/4000 certificate, into the Mule application, then set up JVM parameters for the CloudHub application to use that trust store instead of the worker JRE’s defaults.

Note that the upcoming infoConnectfor MuleSoft version 2.1.4 will address this issue in a more user-friendly way and support the trust store configuration via standard Mulesoft TLS context. We plan to release this feature by the end of this year. Meanwhile, here are the detailed instructions on how to set the JVM parameters for Mule 4 CloudHub workers. The same method applies to any other scenario where certificates must be explicitly trusted by the Mulesoft application without the option to set up a custom TLS context, for example for custom DB connections.

• Confirm that the CloudHub VPC is configured to access the back-end IBM i (AS/400) with the correct ports listed at the bottom of this article.
• Perform the IBM i (AS/400) configuration steps per instructions. At the end of this step, you will have the custom trust store with the IBM i (AS/400) certificate.
• Next, a very important step is to import the standard certificates, shipped by default with Java runtimes, into this custom trust store:

keytool -importkeystore -srckeystore <cacerts> -srcstorepass changeit -destkeystore <custom-truststore> -deststorepass <custom-truststore-password>

This step is required in order for the CloudHub worker to successfully communicate with other Anypoint APIs  (monitoring, logging, etc) via HTTPS.

• Place the custom trust store file with all the standard root certificates as well as the IBM i (AS/400) certificate, into the Mule application’s /src/main/resources folder. In the Mulesoft app’s IBM i (AS/400) connection configuration, set Secure Connection = true

• Package the Mule app and set the following properties when deploying the app to CloudHub:

javax.net.ssl.trustStore=/opt/mule/mule-<runtime-version>/apps/<mule-app-name>/<custom-truststore-name>  
javax.net.ssl.trustStorePassword=<custom-truststore-password> 

Running into connection issues after following the steps? Below are the likely reasons:

• IBM i (AS/400) certificate is not applied to one of the Host services below
  • Central
  • Database
  • Data Queue
  • Remote Command
  • Sign on
  • DDM / DRDA
  • File server

• Required IBM i (AS/400) ports are not accessible from the Mulesoft worker. Below is a list of ports required for a secure connection:
  • Secure connection
    • 449, 448, 9470, 9471, 9472, 9473, 9475, 9476
  • Non-secure connection
    • 449, 446, 8470, 8471, 8472, 8473, 8475, 8476

• The trust store file is not found due to an incorrect path, or the trust store password is not valid
  • Review the application log or add javax.net.ssl.debug=ssl to the application properties on CloudHub and confirm that the application does use the custom trust store and can successfully access the IBM i (AS/400) certificate

• IBM i (AS/400) version is older than 7.1 and works with old syphers not supported by the JVM.
  • This would be a very good reason to seriously consider the OS upgrade.

The above configuration will help customers securely connect to IBM i (AS/400) from Mulesoft CloudHub apps. The same method could be used for leveraging a custom trust store for any other Mulesoft connectors that do not support the standard Mulesoft TLS context. Keep an eye out for an upcoming infoConnect release 2.1.4 where developers will be able to configure standard Mulesoft TLS context. Feel free to reach out if you have very specific IBM i (AS/400) or Mulesoft connectivity requirements – our Professional Services team is always ready to help!