Just wanted to know what is the default TLS version that Active Transfer uses? I am working on Active Transfer 10.7 and we have a virtual folder management created using FTPS protocol but we are getting an error “Unsupported or unrecognized SSL message”. I am suspecting this has something to do with TLS version that we are using. I think they require us to use a lower version of TLS1.0 to connect to the end system. And is there a way or a configuration where we can specify what TLS version to use when doing an FTPS connection through virtual folder?
I’d wager that this is a Java restriction, as opposed to IS (i.e., AT).
The following steps should work for AT as well, since it is hosted on an IS. I won’t recommend using TLSv1 (or TLSv1.1 for that matter), but if you absolutely must, then try this -
Navigate to /SAGInstallationPath/jvm/jvm/jre/lib/security folder
I can only see the following on the wrapper.log. We wanted to increase the log level to debug to further check the issue but we do not know a way to increase log level here on wrapper.log.
INFO | jvm 3 | 2021/08/09 07:17:39 | 07:17:39.426 [HTTP Handler 10.44.76.45] INFO com.softwareag.mft.external.session.ftp - [:7969730] Connecting to:*********:21
INFO | jvm 3 | 2021/08/09 07:17:39 | 07:17:39.439 [HTTP Handler 10.44.76.45] INFO com.softwareag.mft.external.session.ftp - [:7969730] Output stream:null, written:QUIT
Thanks for the response KM. We will try this out. Can you also elaborate on the Java restriction? Maybe we can check this side as well. By the way we are trying to connect through Mainframe which they mentioned and might be using older version of TLS.
I was able to get more logs by running the through event management. The event is calling the vfs through the virtual folder option on the event we created. This are the one captured on the wrapper.log
ENUE. Error javax.net.ssl.SSLException: Unsupported or unrecognized SSL message
INFO | jvm 3 | 2021/08/09 07:29:43 | at com.softwareag.mft.activetask.plugins.MoveTask.run(MoveTask.java:55) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | … 41 more
INFO | jvm 3 | 2021/08/09 07:29:43 | Caused by: com.softwareag.mft.common.exception.MFTException: Error executing Move_to_CIS_REVENUE. Error javax.net
.ssl.SSLException: Unsupported or unrecognized SSL message
INFO | jvm 3 | 2021/08/09 07:29:43 | at com.softwareag.mft.activetask.plugins.Task.handleException(Task.java:773) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | at com.softwareag.mft.activetask.plugins.CopyTask.doCopy(CopyTask.java:599) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | at com.softwareag.mft.activetask.plugins.MoveTask.run(MoveTask.java:46) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | … 41 more
INFO | jvm 3 | 2021/08/09 07:29:43 | Caused by: java.lang.Exception: javax.net.ssl.SSLException: Unsupported or unrecognized SSL message
INFO | jvm 3 | 2021/08/09 07:29:43 | at com.softwareag.mft.activetask.plugins.CopyTask.doCopy(CopyTask.java:549) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | at com.softwareag.mft.activetask.plugins.MoveTask.run(MoveTask.java:46) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | … 41 more
INFO | jvm 3 | 2021/08/09 07:29:43 | Caused by: javax.net.ssl.SSLException: Unsupported or unrecognized SSL message
INFO | jvm 3 | 2021/08/09 07:29:43 | at org.openjsse.sun.security.ssl.SSLSocketInputRecord.handleUnknownRecord(SSLSocketInputRecord.java:452) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | at org.openjsse.sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:175) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | at org.openjsse.sun.security.ssl.SSLTransport.decode(SSLTransport.java:110) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | at org.openjsse.sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1445) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | at org.openjsse.sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1351) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | at org.openjsse.sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:463) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | at org.openjsse.sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:434) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | at com.softwareag.mft.client.FTPClient.login(FTPClient.java:147) ~[com.softwareag.mft.tunnel_10.7.0.0002-0545.jar:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | at com.softwareag.mft.client.session.SessionManager.getClient(SessionManager.java:167) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | at com.softwareag.mft.activetask.plugins.Task.getClient(Task.java:718) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | at com.softwareag.mft.activetask.plugins.CopyTask.doCopy(CopyTask.java:348) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | at com.softwareag.mft.activetask.plugins.MoveTask.run(MoveTask.java:46) ~[?:?]
INFO | jvm 3 | 2021/08/09 07:29:43 | … 41 more
Please confirm that the server you are trying to connect to does support secure connection.
Do you have any other client that can connect to the server?
Basically, does that FTP server support FTPS or FTPES connection?
If the server does not support FTPS or FTPES, ActiveTransfer cannot enforce secure connection.
My response was a solution for the Java restriction, Paul. As Biswa says above, it looks like AT is using a higher TLS protocol which the Mainframe doesn’t support.
The steps in my aforesaid post should resolve this issue, so that AT uses TLSv1.
Yes the end system supports FTPS. To test this, from the same server where ATS is installed, we have used curl script to connect using FTPS and we are able to connect successfully. Through these curl script we are specifying the user, certificate and version of TLS we used, and the only version that works is on TLS 1.0. Just wondering if this is because ATS is using a higher version of TLS. But since we are not capturing better log i cannot provide more detail information. Another area that i am not sure if i have done correctly is that, we were given a certificate on a PEM format, but the VFS looks for a keystore format. I have converted the PEM file to a PKC12 and import it to a keystore which i followd on this link. Converting PEM-format keys to JKS format.
Since the server supports only TLSv1.0, to find out the root cause of the issue,
we might have to enable debug logs of ssl handshake.
As @Venkata_Kasi_Viswanath_Mugada1 suggested,
we might to have to configure jvm level java security parameters as well.
For the time being, would you please update the following: wrapper.java.additional.106=-Djavax.net.debug=ssl:handshake
in this file: InstallDir\profiles\IS_default\configuration\custom_wrapper.conf
This will enable the debug logs for ssl handshake, which will be available in wrapper.log.
Once you attempt the test connection/event, we will have the required logs.
Please share these logs with us.
You can revert the changes done to customer_wrapper.conf once the logs are collected.
Hi @biswajit and @paulryan.uchi,
The root cause is the change in the latest Java 8 release. As Kasi mentioned earlier, Java 8 build 291 and higher disables TLSv1 and TLSv1.1 by default. For more details, please see April 2021 Java release notes here: Java™ SE Development Kit 8, Update 291 Release Notes.
As Kasi mentioned, edit your java.security file and remove TLSv1 from the jdk.tls.disabledAlgorithms property and restart the ATS to restore the connectivity.
Though we were able to get hold of a patch that fixes the activetransfer log issue. By applying that, the logs are now getting written on activeTransfer.log. Tried to increase the debug level to trace. But this is the only logs i can see during the connection test through VFS.
2021-08-11 19:39:11,353 INFO [com.softwareag.mft.external.session.ftp ][0008] - [:2028690223] Connecting to:MVS3-FTP.PACENT.COM:990
2021-08-11 19:39:11,376 INFO [com.softwareag.mft.external.session.ftp ][0023] - [:2028690223] Output stream:null, written:QUIT
2021-08-11 19:39:11,401 TRACE [com.softwareag.mft.database ][3002] - Total active DB Connections: 1
2021-08-11 19:39:11,404 TRACE [com.softwareag.mft.database ][3002] - Total active DB Connections: 1
Just wanted to provide an update on removing the TLSv1 from the jdk.tls.disabledAlgorithms. After changing that and restarting IS, we are still seeing the same error. We still did not find any other solution and the end system decided to just change the protocol to FTPES. ATS was able to connect using that protocol.
