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?
Put
-Djsse.enableSNIExtension=false
in your appserver VM Options.I have used CXF in several instances where
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:
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: