[
https://issues.apache.org/jira/browse/HTTPCLIENT-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207752#comment-14207752
]
Richard Comblen commented on HTTPCLIENT-1578:
---------------------------------------------
Hi Oleg,
thanks for looking at my report.
What you mention in your previous comment is that using 4.3.6, there is an
alternative implementation using that does not exhibit the issue. Glad to know
about that, and to see that DefaultHttpClient has been deprecated.
Still it does not mean my bug report is invalid, my test is failing as well
with 4.3.6. If there is something wrong in the usage of the library that is
made in the test, please mention it so that I can provide the info to the
author of the Jenkins plugin the exhibit the issue.
Otherwise, I'd be glad if you could either investigate this further, or simply
flag it as WONTFIX as it's about deprecated features, so that again, I can
suggest changes to the author of the Jenkins plugin that exhibit the issue.
Unfortunately, the alternative implementation you suggest is not available with
4.2.5, which is the version shipped with Jenkins, so it cannot be used right
away.
Best,
Richard
> Regression between v4.1 and v4.1.1 regarding validation of SSL certificates
> for servers with multiple VirtualHost serving HTTPS
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1578
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1578
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Reporter: Richard Comblen
>
> We have a service provider hosting a web application (Atlassian Stash) behind
> https proxy. The server hosting this proxy hosts other VirtualHosts using
> https.
> We have a client application (Jenkins) submitting POST requests to that
> application using the httpclient library.
> We realized that starting with version 4.1.1 of the library, we get an SSL
> exception related to hostname verification.
> I've created a minimal example hosted on GitHub:
> https://github.com/rcomblen/HttpClientRegressionTest
> Debugging, you will see that the only certificate retrieved by the SSLSocket
> object corresponds to atlashost.eu (the hosting provider) and not *.kreios.lu
> (our own certificate).
> It seems the library behaves like the openssl command line if you miss the
> -servername argument:
> {code}
> $ openssl s_client -connect stash.kreios.lu:443 2>/dev/null | grep subject
> subject=/description=p7VPQDLL2DWTo7A5/C=PL/ST=Gdansk/L=Gniew/O=Damian
> Nowak/CN=*.atlashost.eu/[email protected]
> $ openssl s_client -connect stash.kreios.lu:443 -servername stash.kreios.lu
> 2>/dev/null | grep subject
> subject=/serialNumber=LwCTQJjJj94odszLnywxXW0AJcv0vdlc/OU=GT98629041/OU=See
> www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated -
> RapidSSL(R)/CN=*.kreios.lu
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
