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:

Answer 1

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

Answer 2

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.

Answer 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.