https URL hostname not matching Common Name (CN) despite setting 'disableCNCheck' to true

Question

I managed to configure my CXF-based client properly so that it finds the correct SSL certificate for the server on which I am running a web service:

  <http:conduit name="https://myserver/myws/register/soap?wsdl:{http://glob.reg.com/myws}.http-conduit">

    <http:tlsClientParameters>
      <sec:keyManagers keyPassword="changeit">
        <sec:keyStore type="JKS" password="changeit"
                  file="C:\Program Files (x86)\Java\jdk1.6.0_45\jre\lib\security\cacerts"/> 
       </sec:keyManagers>
      <sec:trustManagers>
        <sec:keyStore type="JKS" password="changeit"
                  file="C:\Program Files (x86)\Java\jdk1.6.0_45\jre\lib\security\cacerts"/> 
      </sec:trustManagers>
      <sec:cipherSuitesFilter>
        <!-- these filters ensure that a ciphersuite with
             export-suitable or null encryption is used,
             but exclude anonymous Diffie-Hellman key change as
             this is vulnerable to man-in-the-middle attacks -->
        <sec:include>.*_EXPORT_.*</sec:include>
        <sec:include>.*_EXPORT1024_.*</sec:include>
        <sec:include>.*_WITH_DES_.*</sec:include>
        <sec:include>.*_WITH_AES_.*</sec:include>
        <sec:include>.*_WITH_NULL_.*</sec:include>
        <sec:exclude>.*_DH_anon_.*</sec:exclude>
      </sec:cipherSuitesFilter>
    </http:tlsClientParameters>
    <http:authorization>
      <sec:UserName>Betty</sec:UserName>
      <sec:Password>password</sec:Password>
    </http:authorization>
    <http:client AutoRedirect="true" Connection="Keep-Alive"/>

  </http:conduit>

But... because the certificate is for a subdomain name that's different than my server's machine (maps to the same IP address), I am getting the following error:

Caused by: java.io.IOException: The https URL hostname does not match the Common Name (CN) on the server certificate in the client's truststore.  Make sure serv
er certificate is correct, or to disable this check (NOT recommended for production) set the CXF client TLS configuration property "disableCNCheck" to true.
        at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1234)
        at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.onFirstWrite(URLConnectionHTTPConduit.java:183)
        at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:47)
        at org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:69)
        at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1293)
        ... 18 more

So... since this is a development/test system, I did just as the message proposed (set the CXF client TLS configuration property "disableCNCheck" to true):

<http:tlsClientParameters disableCNCheck="true">

Plus, I added the following code to my client's main class (per the suggestion in this thread):

  static {
    HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier()
    {
      @Override
      public boolean verify(String hostname, SSLSession session)
      {
        return true;
      }

    });    
  }

But... I am still getting the same error:

Caused by: java.io.IOException: The https URL hostname does not match the Common Name (CN) on the server certificate in the client's truststore.  Make sure serv
er certificate is correct, or to disable this check (NOT recommended for production) set the CXF client TLS configuration property "disableCNCheck" to true.
        at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1234)
        at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.onFirstWrite(URLConnectionHTTPConduit.java:183)
        at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:47)
        at org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:69)
        at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1293)
        ... 18 more

Any idea why?

I mean, one of the above workarounds should have been enough to let the client ignore the certificate URL mismatch but, in my case, neither works nor the combination thereof.

Why?

Solution 1

I have used CXF in several instances where

<http:tlsClientParameters disableCNCheck="true">

was sufficient to disable CN check.

Are you certain your client is using that conduit configuration? My understanding is the conduit name pattern needs to match the endpoint URI in some fashion.

Try setting the conduit name as follows such that any endpoint will match and see if that changes anything:

<http:conduit name="*.http-conduit">

Update 2 Jan 2015

It turns out the http-conduit configuration name matching has two pattern formats. One involves the service's namespace and port name. The other supported format is a regular expression matched against URL endpoint specified in WSDL used to create client.

Quoting Apache CXF User Guide regarding the http-conduit element:

The name includes the service's namespace, the WSDL port name (as found in the wsdl:service section of the WSDL), and ".http-conduit". It follows this template:

{WSDL Namespace}portName.http-conduit

Note: it's the PORT name, not the service name.

..

Another option for the name attribute is a reg-ex expression (e.g., "http://myserver.example.com:*") for the ORIGINAL URL of the endpoint. The configuration is matched at conduit creation so the address used in the WSDL or used for the JAX-WS Service.create(...) call can be used for the name.

Solution 2

Put -Djsse.enableSNIExtension=false in your appserver VM Options.

Solution 3

Add below code to set disableCNCheck

 HTTPConduit httpConduit=(HTTPConduit)ClientProxy.getClient(port).getConduit();
        TLSClientParameters tlsCP = new TLSClientParameters();
        tlsCP.setDisableCNCheck(true);
        httpConduit.setTlsClientParameters(tlsCP);

Use this code only in the lower environments, In higher environments, it's not recommended.

Comments

[David J. Liszewski]

Note: this will disable CN checking for all other SSL connections in that JVM process. #justsayin

[Dark Star1]

I tried this in my project (configured the intelliJ maven runner to add this switch) and that didn't work.