Thanks for that Brad -- it was some kind of problem with the server certificate JKS file.
The error message is misleading; worth a bug report? For ftpserver or for MINA? Or is it something that the Java security API prevents fixing? On 26 January 2011 23:17, Brad McEvoy <[email protected]> wrote: > > I had the same problem recently (not with apache ftp, but with another > server, but i think its all the same under the hood), and of course the > problem wasnt anything to do with missing cipher suites. > > Can't remember exactly what it was but it was just a config error. It > caused an exception deep down in the bowels of java ssl which was swallowed > with being logged. Once i saw what that exception was it was immediately > obvious what i had done wrong. > > I eventually found the problem with java debugging stepping through the ssl > initialisation. > > > On 27/01/11 11:47, John Hartnup wrote: > >> This is very strange. I've not been able to reproduce my one successful >> run. >> >> I definitely have *no* enabled-ciphersuites attribute right now, so it >> should support a healthy set of ciphersuites. >> >> Without the "-z cipher" parameter, openssl's hello requests the same 26 >> ciphersuites. >> >> Is there a way to get ftpserver to list the ciphersuites it supports? >> >> I've tried on a few of the JVMs that I have on my box. >> >> On 26 January 2011 18:30, Niklas Gustavsson<[email protected]> wrote: >> >> On Wed, Jan 26, 2011 at 6:09 PM, John Hartnup<[email protected]> >>> wrote: >>> >>>> If I don't specify a ciphersuite, according to the documentation, the >>>> >>> server >>> >>>> should accept every ciphersuite available to Java. Yet it is the Java >>>> >>> side >>> >>>> that is reporting "no matching ciphersuite", and sending the SSL alert >>>> in >>>> response to the client hello. >>>> >>> That's correct, if no cipher suites are listed, all will be active. >>> Make sure you do not have the attribute with an empty string, that >>> will cause all cipher suites to be disabled. Also, you do not need to >>> specify client-authentication="NONE" as that's the default value. >>> >>> On the client, does it make any difference to remove the use of -z >>> cipher-ALL ? >>> >>> /niklas >>> >>> >> >> > -- "There is no way to peace; peace is the way"
