commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bogdan Drozdowski (JIRA)" <>
Subject [jira] Commented: (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode
Date Fri, 11 Mar 2011 16:38:01 GMT


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
> -----------------------------------------------------------------------------------------------
>                 Key: NET-326
>                 URL:
>             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 :
> No available certificate or key corresponds to the SSL cipher
suites which are enabled.
> 	at
> 	at
> 	at
> 	at
> 	at
> 	at
> 	at fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.testFTPS(
> 	at fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.main(
> 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

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message