[
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007541#comment-13007541
]
Bogdan Drozdowski commented on NET-326:
---------------------------------------
Quick fixing :)
Now that I see that the code has grown a bit, wrapping the other calls makes
little sense. But now creating more methods, similar to the above (with an
explicit algorithm or provider), with an extra parameter of a KeyStore makes
more sense.
Now the question is: will we always have an instance of X509TrustManager?
Keytool allows creating other keys, not only RSA. But I'm not sure. Anyway,
perhaps the best solution is leave it as it is and have the user catch a
ClassCastException if something went wrong. The only thing we could do is
search the array for the first instance of X509TrustManager, which could in
turn, return the non-first element (could it still be called "the default"?),
which could cause even more mess. I'm just thinking out loud, probably these
problems will never happen, because the user should have prepared a proper
keystore in the first place.
I've just remembered: if you accept my file, add a "@see" tag to the
contructors that use SSLContexts and, independly of that, add a "@see" tag to
the TrustManager-setters in FTPSClient, SMTPSClient and POP3SClient, so the
users can find the new class.
> 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
> Attachments: SSLContextsFactory.java
>
>
> 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
