0

Our company has upgraded from TLS 1.0 to TLS 1.2. Before this, we used to download files using org.apache.commons.net.ftp.FTPClient.

Now we cannot connect to the server using FTPSclent and we get an exception:

org.apache.commons.net.ftp.FTPConnectionClosedException: Connection closed without indication

How can I correctly connect to the server.

Full stack trace:

enter image description here

assylias
  • 321,522
  • 82
  • 660
  • 783
lyjsh
  • 1
  • 1
  • 1
  • Can you please paste the stack trace as text instead of an image? It's easier to read and easier to search for people having similar issues. – assylias Aug 27 '18 at 10:05
  • To me it seems more on network side rather on coding. It seems that only client you upgraded and server using incompatible version – Nishant Modi Aug 27 '18 at 10:20
  • If you move to Java 8, you get TLS 1.2 by default. If you need to stick with JRE 7, there are two options, the first is if you have Oracle support for the JVM, they have a special non-public build that includes it. If not, you have to do it in code. Look at this post for creating the SSL Context and forcing use of TLS 1.2 https://stackoverflow.com/questions/39157422/how-to-enable-tls-1-2-in-java-7 – Mike Aug 27 '18 at 13:29
  • Just an FYI, most of the switches are for HTTPS and don't apply to FTPS. There are some new ones, but I don't think they were added until Java 8 or Java 9. I have never been able to get any of them to work. – Mike Aug 27 '18 at 13:31

1 Answers1

3

First of all, turn on the SSL debug as the javadoc sugests and try to connect, then check the output (it logs by default to std out, you should redirect it to a file).

The sorter answer

Give a try to the -Dhttps.protocols=TLSv1.2 JVM argument (this should be passed to every java code that you are using during your investigation and you have to use the same JRE of course too).

If does not work, check the server certificate, that should be installed to the JRE's default keystore (cacerts) or your custom keystore that you may use.

If this does not help, install the JCE extensions (JRE could not handle a cert that has at least 2048 bit key without JCE).

If all of these steps are useless, you may have the same problem than this guy.

The longer version

I hope that you are using at least Java7 (see the table of the available protocols on each platform).

The first thing is, that the TLS protocols supported by the server and supported by your application have to have an intersect.

In this table you can find the default TLS protocols of the different JRE versions, this is important because your client uses very probably the default TLS of the JRE.

So after you have checked your JRE and found the supported TLS versions, you should check the applied cyphers.

You should test your connection using nmap: nmap.exe --script ssl-enum-ciphers -p <port> <ftp host> with this tool, you can list the TLS version and the used cyphers. The cypher list can be compared with the list provided by this small java code. This two lists have to have at least one common point in order to be able to communicate.

You can download the server's certificate using Portecle, that certificate should be installed in the keystore of your client JRE.

If you have found that they have intersection in TLS protocols and in cyphers too, you have the right cert in your keystore, you can test that they can communicate with SSLPoke

If this works too, then the problem should be in FTPClient.

m4gic
  • 1,461
  • 12
  • 19
  • The ftp server was provided by other company,so I should get the keystore from they ? – lyjsh Aug 28 '18 at 01:37
  • You have to obtain the certificate used by the connection. It would be faster to use portecle and use the examine connection feature where you can give a host and a port, and you can check and download the used certificate(s). These certs should be imported to the client's keystore. – m4gic Aug 28 '18 at 07:51