[jira] [Comment Edited] (NET-605) FTPSClient forces IP in SubjectAlternativeNames field for server certificate validation instead of hostname

["Adam Lynam (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NET-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15741883#comment-15741883 ] 

Adam Lynam edited comment on NET-605 at 12/12/16 1:28 PM:
----------------------------------------------------------

The answer to this is probably setting the original hostname, instead of the IP (held in the host variable), when creating the SSLSocket inside FTPSClient on line 268:

SSLSocket socket =
            (SSLSocket) ssf.createSocket(_socket_, host, port, false);

I am not sure what other impact this might have though.


was (Author: adam.lynam.dwp):
The answer to this is probably setting the original hostname, instead of the IP (held in the host variable), when creating the SSLSocket:

SSLSocket socket =
            (SSLSocket) ssf.createSocket(_socket_, host, port, false);

I am not sure what other impact this might have though.

> FTPSClient forces IP in SubjectAlternativeNames field for server certificate validation instead of hostname
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: NET-605
>                 URL: https://issues.apache.org/jira/browse/NET-605
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>    Affects Versions: 3.5
>            Reporter: Adam Lynam
>
> We have an FTP Server with a signed certificate, with both CN and SAN DNS entries set to the respective hostname of the machine.
> When attempting to connect using FTPSClient, we get java.security.cert.CertificateException: No subject alternative names matching IP address x.x.x.x found. The FTPSClient appears to resolve the IP address and pass that through the SSLSocket where it eventually raises the exception.
> While we initially encountered the error against our internal FTP server, we have confirmed the same issue against a public FTP server. ftps://demo:password@test.rebex.net.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)