commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bogdan Drozdowski (JIRA)" <j...@apache.org>
Subject [jira] Commented: (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode
Date Sun, 13 Mar 2011 15:08:59 GMT

    [ 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

Mime
View raw message