[
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:[email protected].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
