[
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005711#comment-13005711
]
Bogdan Drozdowski commented on NET-326:
---------------------------------------
I think this could be done, but remember that there are a few parameters in the
code, as you can see:
* the protocol
* the Provider or a provider String (for SSLContext.getInstance(), not used
here)
* the KeyManagerFactory type
* the KeyStore type
* the filename of the KeyStore
* the password to the KeyStore
* the TrustManager
* a SecureRandom instance (the "null" parameter in ctx.init() above)
It ceratinly would be possible to create a few overloaded methods that take
different number of parameters from the above list. If a parameter is null or
not present in some version of the utility method, use the one from the code
above.
It would be easier for users, because in the simplest version they would only
need to create a keystore and provide the filename and password to the method
and they would get a ready-to-use SSLContext for use in the constructor (so, of
course, the overloaded methods would have be "public static", if they would be
in FTPSClient). I didn't think of that, but you're right - we should make it
easier for the users. The simplest version (filename+password) would surely be
easier to use than writing all the above by hand after, say, an hour of
browsing the Web. The more parameters will there be in the "biggest"
declaration, the better for the more advanced users (less assuming by us, most
possibilities for the users).
The problem is that supporting all combinations of parameters would probably
produce many methods. These would probably have to be put in a separate module.
The minimum is one method (with all the parameters passed from outside), but it
would be hard to use, so the real minimum should be 2 methods (one with all the
parameters and one just with the filename and the password).
Conclusion: yes, there is a point in implementing this. Perhaps even not only
in the "ftp" package, but somewhere above, because, in theory, even POP3, SMTP
and other servers where SSL/TLS is used, could require user authentication by
certificate (apart from the password later on).
> A KeyManager is required when the protection level is set to 'P' with
> FTPSClient on active mode
> -----------------------------------------------------------------------------------------------
>
> Key: NET-326
> URL: https://issues.apache.org/jira/browse/NET-326
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.0
> Environment: Windows XP profesional service pack 2, Java Java
> 1.6.0_12-b04
> Reporter: Terence Dudouit
>
> Using a simple FTPS client that list a directory, when execPROT("P") is set
> and the active mode is on, the following exception is thrown :
> javax.net.ssl.SSLException: No available certificate or key corresponds to
> the SSL cipher suites which are enabled.
> at
> com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
> at
> com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
> at
> org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:489)
> at
> org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
> at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1950)
> at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1996)
> at
> fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.testFTPS(FTPGet.java:379)
> at
> fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.main(FTPGet.java:401)
> This doesn't occur on passive mode.
> The only way to make it work is to set a keyManager although there is no need
> for a client authentication.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
