[
https://issues.apache.org/jira/browse/HTTPCLIENT-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17333138#comment-17333138
]
ASF subversion and git services commented on HTTPCLIENT-2149:
-------------------------------------------------------------
Commit 58a17cc549a60b54d78edf6b4a25e92ad948c0da in httpcomponents-client's
branch refs/heads/5.2.x from Peter Dettman
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=58a17cc ]
HTTPCLIENT-2149: When no dNSName, match against CN
> DefaultHostnameVerifier should use CN matching when no dNSName present
> ----------------------------------------------------------------------
>
> Key: HTTPCLIENT-2149
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2149
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Reporter: Peter Dettman
> Priority: Minor
> Fix For: 5.0.4, 5.1-beta2
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> [RFC 2818 3.1|https://tools.ietf.org/html/rfc2818#section-3.1] says: "If a
> subjectAltName extension of type dNSName is present, that MUST be used as the
> identity. Otherwise, the (most specific) Common Name field in the Subject
> field of the certificate MUST be used."
> Consider a certificate having a (non-empty) subjectAltName extension
> containing only entries of type SubjectName.IP, and suppose that
> DefaultHostnameVerifier.verify(String, X509Certificate) is called with a host
> of type HostNameType.DNS. Then matchDNSName will be called to try and match
> host against subjectAlts and will fail since there are no dNSName entries to
> match against.
> However per the RFC 2818 requirement above, having found no dNSName entries,
> the check should fall back to matching against the CN.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
