Hello Experts,

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?

Thanks.

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 -

1. Navigate to /SAGInstallationPath/jvm/jvm/jre/lib/security folder
2. Edit the java.security file
3. Find the key jdk.tls.disabledAlgorithms
4. Remove TLSv1 from the list of disabled algorithms
5. Restart the IS and try the JDBC connection again

MicrosoftTeams-image (5)740×105 5.78 KB

KM

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.

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.

KM

Hi Paul,

Can you please share the wrapper.log when we we are seeing this issue.

Regards
Biswa

Hi Biswa,

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

Hi @biswajit

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

Hi Paul,

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.

Regards
Biswa

Hi @biswajit,

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.

Hi Paul,

Thanks for details.

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.

Regards
Biswa

HI @biswajit ,

Apology for the delay I tried changing this but i don’t see any additional logs being written to the wrapper.log.

Here is the snippet of the the custom.wrapper.cnf

wrapper.java.classpath.3=/app/107softwareag/IntegrationServer/instances/…/…/common/lib/wm-converters.jar
wrapper.java.initmemory=256
wrapper.java.library.path.11=/app/107softwareag/IntegrationServer/instances/default/lib
wrapper.java.library.path.append_system_path=TRUE
wrapper.java.maxmemory=1024
wrapper.jvm_exit.timeout=300
wrapper.on_exit.42=RESTART
wrapper.ping.timeout=300
wrapper.restart.reload_configuration=TRUE
wrapper.shutdown.timeout=300
wrapper.single_invocation=TRUE
wrapper.working.dir=/app/107softwareag/IntegrationServer/instances/default
#wrapper.java.additional.106=-Djava.security.properties=config/security/webm_override_java.security
wrapper.java.additional.106=-Djavax.net.debug=ssl:handshake

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

Paul, did you try the solution I provided, above?

KM

Hi KM,

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.

Thanks for getting back, Paul.
This is strange to me, so if you’d like to get to the bottom of this, do create a support ticket.

KM

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.