The library doesn't understand that out-of-the-box. It will always perform a handshake using TLSv1 instead. This happens even after the initial handshake was done in TLSv1.2 in the rest of the program. adding -Djavax.net.debug=ssl:handshake:verbose reveals that the ClientHello would always successfully be established on v1.2 but the next call would be another ClientHello in v1 afterwards. Neither of -Dhttps-protocols=TLSv1.2 nor -Djdk.tls.client.protocols=TLSv1.2 helped. This helped with getting the debugging to this stage.
The SSL plugin found on Github was one possibility, but I was hoping to find a solution which is more lightweight. Initially, I found this, which hinted at configuring the AxisProperties. The rabbit hole lead me to the suggestion of customising the SecureSocketFactory next. Digging deeper, I finally found the setting that "unlocked" TLSv1.2 for Axis. It was the setEnabledProtocols that mostly did the trick, and allowed me to get a move on.
With the customised SocketFactory, setEnabledProtocols, I could finally run the program as such
<JAVA_HOME>/bin/java -Dhttps.protocols="TLSv1.2" -Djava.security.properties=java.security -jar MyApp.jar
The java.security file was merely a text file containing 2 empty property assignments:
ssl.SocketFactory.provider=
ssl.ServerSocketFactory.provider=
It certainly helps starting off the week in a good way.
Under some scenario, the setting to unlock the TLS 1.2 in Axis 1.4 is the "org.apache.axis.components.net.SocketFactory" system property instead of the "org.apache.axis.components.net.SecureSocketFactory"
ReplyDelete