[
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006205#comment-13006205
]
Bogdan Drozdowski commented on NET-326:
---------------------------------------
isClient/ServerTrusted(): I believe we don't need these anymore. I left them
because the code I've found on the 'net used them and I figured these may be
required for backwards-comaptibility and this was my only reason. Now I'm
thining that the backward-compatible version perhaps required classes from
javax.security.cert (instead of the new java.security.cert), so this
compatibility may not be retained anyway.
checkServertrusted(): wasn't commented-out in FTPSTrustManager, but since we're
accepting everything, I'm not even validating. Validating the certificates
could cause Exceptions, so we could validate not all certificates. What to do
is the right question. If the server certificate has expired or is self-signed
or is not signed by a certificate a user has in his/her trust store, should we
reject it even if it would provide encryption?
Yes, the accept-all TrustManager looks like the other (except for the disabled
code, perhaps). It came from the Web, while POP3TrustManager and
SMTPSTrustManager came from the FTPSTrustManager. I didn't think back then that
these could be combined, I kept my classes in the packages I modified. But
you're right: at this point we're duplicating code, so these certainly can be
combined. And there wouldn't be need for the anonymous class in the
SSLContextsFactory any more.
> 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
