Mule And SSL Debugging

The newer Mule release (I’m currently on 3.8.3) has stopped supporting TLSv1 out of the box. But in some cases, your Mule application may need to “shake hands” with an older application that runs SSL (with TLSv1).

For  an on-prem server, the solution is to modify “MuleHome/conf/tls-default.conf” file, and change this line: enabledProtocols=TLSv1,TLSv1.1,TLSv1.2

Please note the exact spelling of “TLSv1”.

If you want to make the change for Anypoint Studio, I found this file under “StudioHome\plugins\org.mule.tooling.server.3.8.1.ee_6.1.0.201610271207\mule\conf” (you may have a different path, you can find it by searching “tls” from your studio home directory).

Here are a few side notes about the behavior of this file:

1. In the past, I remember you can make a local copy of “tls-default.conf” in your project “main/resources” directory, based on my test in the Studio, that doesn’t work anymore (I have Studio version 6.2.3). I didn’t test deploying to the server. I suspect it’s the same behavior.
2. I tested with both Java 7 and 8 in the Studio, the “TLSv1” change works with both Java versions (under preferences->Java->Installed JREs)
3. I also tried to tweak TLS/SSL under HTTP request configuration, it doesn’t work. It appears the “Adavnced->Enabled Protocols” under there can only use a subset of protocols from the “tls-default.conf” file. So if “TLSv1” is not in that file, and you put it in “Enabled Protocols” field, you will get an error. I surmise, what you can put in here (including Enabled Cipher Suites) can only further restrict what can be used, but not add new options that are not in that file.
4. Generally speaking, you should ask the other party to upgrade to TLS 1.1 or TLSv1.2, instead of bending backwards. Because the change is global, it affects all applications running on the server.
5. I have not tested whether this can be done in Cloudhub. If I ever test it, i’ll update this post.

Since we are talking about SSL, let me segue into a general SSL debug with Mule, because I had to go through these to eventually figure out the solution.

Choosing a Global Software Development Partner to Accelerate Your Digital Strategy

To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.

Get the Guide

By default, Mule logging doesn’t show SSL details. Here are a few options to enable SSL logging.

For an on prem-server, you can modify the Mule startup script or wrapper.conf to to play with these options:

-Djavax.net.debug=all, or -Djavax.net.debug=ssl:handshake, or  -Dsun.security.ssl.allowUnsafeRenegotiation=true, or simply  Java “-verbose”

If you are testing in Studio, you can set these options by right clicking on the project name, then “Run As-> Mule Application (configure) -> Arguments”. Put in VM arguments.

I even used some of these flags to debug “amc_setup”, because we originally got an SSL error. Although eventually it turned out the “amc_setup” issue was not SSL problem, it’s the server proxy. We had to use “amc_setup” with option “-P proxyHostName ProxyPort” to get it going.

Another common SSL related issue is self-signed or invalid (or imperfect) certificate. Here are two ways that may help resolving the issue:

1. download the public certificate (in newer chrome, go to “settings->advanced->manage certificates), then use ,

   keytool -importcert -file "your.cer" -keystore your.jks -alias "<anything>"

then store the jks file in the trust store as in TLS config (make sure it’s the trust store, not the keystore).

2. use the following in HTTP requester config

<tls:context name=”test” > <tls:context name=”test” > <tls:trust-store insecure=”true”/> </tls:context>

Folks, that’s it!