3

The similar question has been answered many times before but I have a pretty strange behavior. Using Jersey client implementation the code works fine and I get the '200 OK' status. However, If I use RestEasy's client I get the above exception. Now the code:

public class SSLErrorTest {
 public static void main(String [] args) {
   WebTarget webTarget = ClientBuilder.newClient().target(
        "https://foo.bar.com/path/to/my/resource);
    Response response = webTarget.request().header(
        "Authorization",
        "myAuthToken"
    ).header(
        "Accept", "application/json"
    ).get();
    System.out.println("Response Code : " + response.getStatusInfo().
 }
}

The response for the get() method using Jersey client: OK The response for the get() method using RestEasy client is the above SSL exception with the message: "foo.bar.com" != "bar.com". The dependencies I switch between:

<dependencies>
    <dependency>
        <groupId>org.jboss.resteasy</groupId>
        <artifactId>resteasy-client</artifactId>
        <version>3.0.8.Final</version>
    </dependency>
<!--
    <dependency>
        <groupId>org.glassfish.jersey.core</groupId>
        <artifactId>jersey-client</artifactId>
        <version>2.16</version>
    </dependency>
-->

Am I missing something essentially important? Thank you!

UPDATE

The host names updated. It did not reflect that one was a subdomain of the other.

UPDATE2

Trying to solve the problem I found out that RestEasy uses Apache HttpClient so I created second class with the main method where I use Apache's HttpClient directly (both Jersey client and Apache client do not throw the above exception). After some debugging I also found out that the session of Apache's client uses TLSv1.2 while RestEasy client's session uses TLSv1. Could this be the root of the weird behavior and if yes, how can I set the TLS' version to 1.2 while using RestEasy's client?

Arthur Eirich
  • 3,368
  • 9
  • 31
  • 63
  • I know that host names are checked to be equal (e.g hostname should be really equal to 'hostname' and not to 'actually the same hostname') but I still can't understand why Jersey doesn't complain about it and RestEasy does. The certificate used on the server side is a self signed one. The root self signed certificate has been used to create the cert for the server. Maybe this will also help... – Arthur Eirich Mar 06 '15 at 09:21
  • found this link which seems to describe the same issue: https://bugzilla.redhat.com/show_bug.cgi?id=1048208 – Arthur Eirich Mar 06 '15 at 09:35

1 Answers1

2

I think you should set HostnameVerificationPolicy.ANY parameter for your ResteasyClientBuilder. In your case it can fit value HostnameVerificationPolicy.WILDCARD that Allows wildcards in subdomain names i.e. Example:

ResteasyClient client = new ResteasyClientBuilder().hostnameVerification(ResteasyClientBuilder.HostnameVerificationPolicy.ANY).build();
Владимир Береза
  • 75
  • 2
  • 6