Thanks Sai. That was exactly my problem. We downgraded to SSL to fix it (the client has issues with TLS on AIX).
-----Original Message----- From: Sai Pullabhotla [mailto:[email protected]] Sent: Wednesday, February 04, 2009 9:45 AM To: [email protected] Subject: Re: SSL setup problems... This is an issue with IBM's JVM where they decided to change things around in Java 1.5. The thing that they changed is the implementation of getInstance() method in SSLContext class. The SunJVMs work fine with SSL/TLS peer when you initialized the SSLContext with SSLContext.getInstance("TLS"). The same used to work fine in IBM's JVM in version 1.4. However, they decided not to do so in 1.5. When I spoke to their Support, they said that they are not going to change it back bacause they changed it for a reason in the first place. With the newer IBM's JVM, the call to SSLContext.getInstance("TLS") only works if the other end is actually using TLS. If the other end uses SSL, IBM's JSSE thows a handshake exception. If you want your application to connect to either SSL or TLS, you need to initialize the SSLContext by passing "SSL_TLS" as the protocol. More information on this can be found on the IBM's Java web site (I found it a long time ago, hope you can still find it). The answer to your question is, there won't be any 'real' issues specifying "SSL_TLS" other than the fact that you are supporting both SSL and TLS for your FTP clients. Your server might be vulnerable to all known issues in SSL v3, if any. Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Tue, Feb 3, 2009 at 10:43 AM, West, John C <[email protected]>wrote: > > > So everything is not fine after all. > > After dancing around a load of internal networking issues, I'm now > getting: > javax.net.ssl.SSLHandshakeException: Client requested protocol SSLv3 > not enabled or not supported > > on the data connection (PASV). Here's my listener config: > <listeners> > <nio-listener name="default" port="30021" > implicit-ssl="false"> > <ssl> > <keystore file="conf/keystore.jks" > password="password" key-alias="key" algorithm="IbmX509" /> > <truststore file="conf/keystore.jks" > password="password" algorithm="IbmX509" /> > </ssl> > <data-connection idle-timeout="60"> > <active local-port="40021" /> > <passive ports="40021-40049" /> > </data-connection> > > </nio-listener> > </listeners> > > > As you can see, I'm not specifying SSL or TLS. The control connection > works fine (over TLS) and then the client tries to open the data > connection using SSLv3 and that's when I get the error. I wrote a > quick app to list out the protocols supported by the jre I'm using and > I got [SSLv3, TLS, TLSv1, SSL, SSL_TLS] so SSLv3 is available. > > While the client team tries to figure out how to use TLS for both, I > thought I'd do some investigating. Is leaving the protocol out of the > ssl tag the same as specifying SSL_TLS? Would there be any issues > mixing TLS/SSL? > > > > > -----Original Message----- > From: West, John C > Sent: Thursday, January 29, 2009 10:39 AM > To: [email protected] > Subject: RE: SSL setup problems... > > > That's what I thought, but he was insistent that the cert is all > that's required. > > I generated a new key and installed it, but it still didn't work. It > turned out that the subsequent issue was caused by the client not > playing well with implicit-ssl=true. I changed that and everything > works fine now. > > Thanks for your help. > > > > -----Original Message----- > From: Niklas Gustavsson [mailto:[email protected]] > Sent: Monday, January 26, 2009 4:43 PM > To: [email protected] > Subject: Re: SSL setup problems... > > On Mon, Jan 26, 2009 at 10:26 PM, West, John C > <[email protected]> wrote: > > I have a keystore (conf/keystore.jks) with one certificate: > > % keytool -list -keystore conf/keystore.jks Enter keystore password: > > password > > > > Keystore type: jks > > Keystore provider: IBMJCE > > > > Your keystore contains 1 entry > > > > xfer, Jan 26, 2009, trustedCertEntry, Certificate fingerprint (MD5): > > 80:40:2D:97:25:20:AD:50:BE:9D:06:CA:B0:77:CA:EB > > This is not sufficient, you need to have at least a key for the server > to use. You can generate this using keytool -genkey. > > > My ftpd.xml has the following configuration: > > > > <listeners> > > <nio-listener name="default" port="30021" > > implicit-ssl="true"> > > <ssl protocol="SSL" > > client-authentication="WANT"> > > Noramlly, you do not need these attributes. > > > <keystore file="conf/keystore.jks" > > password="password" key-alias="xfer" algorithm="IbmX509" /> > > You do not need the key-alias attribute if the keystore only contains > your key. I'm not sure if you need the algorithm, but I would not > think so. > > > <truststore file="conf/keystore.jks" > > password="password" algorithm="IbmX509" /> > > Again, algorithm might not be needed. > > That should be it, let us know if it helps or not. We can probably > improve our error logging in this area, I'll have a look at that after > 1.0. > > /niklas > > > > ----------------------------------------- > Use of email is inherently insecure. Confidential information, > including account information, and personally identifiable > information, should not be transmitted via email, or email attachment. > In no event shall Citizens or any of its affiliates accept any > responsibility for the loss, use or misuse of any information > including confidential information, which is sent to Citizens or its > affiliates via email, or email attachment. Citizens does not guarantee > the accuracy of any email or email attachment, that an email will be > received by Citizens or that Citizens will respond to any email. > > This email message is confidential and/or privileged. It is to be used > by the intended recipient only. Use of the information contained in > this email by anyone other than the intended recipient is strictly > prohibited. If you have received this message in error, please notify > the sender immediately and promptly destroy any record of this email. > > ----------------------------------------- Use of email is inherently insecure. Confidential information, including account information, and personally identifiable information, should not be transmitted via email, or email attachment. In no event shall Citizens or any of its affiliates accept any responsibility for the loss, use or misuse of any information including confidential information, which is sent to Citizens or its affiliates via email, or email attachment. Citizens does not guarantee the accuracy of any email or email attachment, that an email will be received by Citizens or that Citizens will respond to any email. This email message is confidential and/or privileged. It is to be used by the intended recipient only. Use of the information contained in this email by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender immediately and promptly destroy any record of this email.
