I want to set up this variable, but I can’t seem to find it in the MSR site. The Settings > Extended menu does not display this variable, but ‘disableProtocols’ existed. The documentation said enabledProtocols existed, but I can’t find that anywhere. So where do I modify the enabledProtocols?
EDIT: The problem here is that when I tried to hit a site via pub.client:http, I got the message ‘SSLHandshakeException: The server selected protocol version is not accepted by client preferences [TLS13, TLS12, TLS11]’. So I thought those enabledProtocols would help.
When I did put that watt.net.jsse.client.enabledProtocols (or check list the watt.net.jsse.client.disabledProtocols from the list) and then editing it manually, the result end up being HTTP 504 Gateway Time Out. So I think I might have implemented it wrongly.
@John_Carter4 : When I added those manually, not only it turns into a 504 Gateway Timeout, but after I restored the setting, most of the keys in display on Extended setting vanished that I had to restart. So I think this doesn’t kind of work… or is it something else?
You are right that up until version 10.5, Integration Server used *.enabledProtocols property that controlled the enabled TLS protocols. But with 10.7, when we added TLSv1.3, we decided to just maintain disabledProtocols and updated our migration scripts to automatically converts enabledProtocols to disabledProtocols.
Latest Java 8 updates disables TLSv1 and TLSv1.1 but those were supported when IS 10.7 got released so IS adds them back by using the instances\default\config\security\webm_override_java.security file. But TLSv1 remains disabled as documented. This java security override file makes TLSv1 and TLSv1.1 that JVM disables. Additional note, though TLSv1 is added back through the override file, it is still left as a disabled protocol on watt.net.jsse.client.disabledProtocols=SSLv2Hello,SSLv3,TLSv1 and watt.net.jsse.server.disabledProtocols=SSLv2Hello,SSLv3,TLSv1. Again, the idea with disabled list to let everything else available at the JVM be available for use rather than keep updating an enabled list as each version gets added.
Can you set IS server logger facility 6 to trace and observe the enabled protocols list during that outbound call? Also, if you can enable JSSE debug by adding -Djavax.net.debug=all to your setenv.bat|sh that might also reveal more information.
@Senthil Thanks for the explanation. Although, if I’d like to get around that problem of “SSLHandshakeException: The server selected protocol version is not accepted by client preferences [TLS13, TLS12, TLS11]”, what do you think must be done in my side and the client’s side?
@kristian.wijaya1234, sorry for the delayed response. Hope you managed to get around the problem but if you still have the problem or encounter similar problem in the future, try to enable JSSE debug by adding javax.net.debug=all in the custom_wrapper.conf. This debug log messages can be found in wrapper.log and it will show you what protocol the server selected and that can explain why the client connection is not accepted. Your client preferences include all the latest protocols TLSv1.3, TLSv1.2 and TLSv1.1 and if this doesn’t satisfy the server endpoint then it might be using TLSv1. TLSv1 is disabled in IS 10.7. You can enable it by removing TLSv1 from watt.net.jsse.client.disabledProtocols. After this change your accepted list would include TLSv1 and the connection may get established.