]
R Searls commented on WFLY-7351:
--------------------------------
I tested againts 3.1.2.Final and it works there as well.
JAX-RS Http Client does not support SNI even though underlying Apache
HttpClient version supports it
----------------------------------------------------------------------------------------------------
Key: WFLY-7351
URL:
https://issues.jboss.org/browse/WFLY-7351
Project: WildFly
Issue Type: Bug
Components: REST
Affects Versions: 10.1.0.Final
Environment: N/A
Reporter: Edvin Syse
Assignee: Alessio Soldano
Labels: httpclient, https, jax-rs
Attachments: httpclient-sni-bug.zip
When creating a JAX-RS client using ClientBuilder.newClient() and accessing an SSL
resource configured with SNI, the request fails.
When the request is made you get the default certificate for the ip as it is configured
on the web server instead of the certificate corresponding to the host name you entered.
Attached is a simple Maven project with a rest endpoint that will make a request to
https://www.syse.no/, which is a host configured with SNI. If you access this host with a
client that is not SNI capable, you will get the default certificate instead of the one
corresponding to
www.syse.no. (That cert is actually expired, so that is the underlying
cause reported by the http client in this case. In other cases you will most probably just
get a name mismatch type of error).
This effectively prevents the Http client from being used reliably against a rapidly
growing number of SSL enabled sites, as SNI is the new standard "everywhere" SSL
is configured these days.
The underlying Apache HttpClient version does indeed support SNI. I have tested the
version of Apache HttpClient that is bundled with Wildfly 10.1 and it works correctly.