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

Yannick Dylla commented on HTTPCLIENT-2280:
-------------------------------------------

[~olegk] Thanks for the fast response. Sure that is a valid point.

In my first read of the RFC I only saw:
{quote}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. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.{quote}
With just this paragraph IPs in CN without any subject alts seemed valid. But I 
missed the following paragraph which is a lot stricter for IP addresses:
{quote}In some cases, the URI is specified as an IP address rather than a
hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.{quote}

> HostnameVerifier does not support using IP address in CN
> --------------------------------------------------------
>
>                 Key: HTTPCLIENT-2280
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2280
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>    Affects Versions: 5.0.4
>            Reporter: Yannick Dylla
>            Priority: Minor
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Hi,
> we are migrating from the 4.x client to 5.x and noticed that the behavior of 
> the DefaultHostnameVerifier changed. Since HTTPCLIENT-2149 
> https://github.com/apache/httpcomponents-client/pull/302 the HostnameVerifier 
> does no longer accept certificates with an ip address in its CN and with no 
> subject alts. Verification fails with "Certificate for <127.0.0.1> doesn't 
> match any of the subject alternative names: []".
> I know using ip addresses in the CN is not really recommended or good 
> practice, but I also see no reason to not use the `matchCN` fallback in this 
> case. The functionality was probably just removed by accident with 
> HTTPCLIENT-2149.
> I will open A github PR with my proposed solution once I know the number of 
> this issue :)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Reply via email to