[ https://issues.apache.org/jira/browse/HTTPCLIENT-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318459#comment-17318459 ]
ASF subversion and git services commented on HTTPCLIENT-2149: ------------------------------------------------------------- Commit 2f4e9836f07e9009764e75a34fec3ea30f02110b in httpcomponents-client's branch refs/heads/5.0.x from Peter Dettman [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=2f4e983 ] 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 > 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