I am trying to write a simple java client for a wso2 esb service, secured using the UsernameToken method. I have difficulties generating the java stubs.
I’ve tried WSDL2Java first but it doesn’t generate a valid pom.xml file and maven can’t resolve the dependencies.
So I’ve decided to try and use JAX-WS RI instead. The stubs get generated and seem fine but I get the following exception when I try to invoke the service.
Exception in thread "main" com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching xxxxxx found
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(Unknown Source)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Unknown Source)
at com.sun.xml.internal.ws.client.Stub.process(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(Unknown Source)
at $Proxy32.getcodelists(Unknown Source)
at com.sirmaitt.esb.codelists.client.Client.main(Client.java:32)
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching xxxxxx found
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Unknown Source)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Unknown Source)
... 15 more
Caused by: java.security.cert.CertificateException: No name matching xxxxx found
at sun.security.util.HostnameChecker.matchDNS(Unknown Source)
at sun.security.util.HostnameChecker.match(Unknown Source)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkIdentity(Unknown Source)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source)
... 27 more
I understood the exception is caused by the self signed certificate the wso2 servers have. What can I do to avoid it?
Is there some easier way to generate valid java stubs for a ssl secured service using the UsernameToken security method? Here is my service definition:
<proxy name="bala-ala" transports="https" startOnLoad="true" trace="disable">
<target>
<endpoint>
<address uri="http://xx.xx.xxx.xx:9766/services/list?wsdl"/>
</endpoint>
<outSequence>
<send/>
</outSequence>
</target>
<publishWSDL uri="http://xx.xx.xxx.xx:9766/services/Codelists?wsdl"/>
<policy key="conf:/repository/axis2/service-groups/bala-ala/services/bala-ala/policies/UTOverTransport"/>
<enableSec/>
</proxy>
You can still use the wsdl exposed in http. (Service is exposed only in https but the wsdls are still exposed in http)
If you want to continue with the wsdl exposed in https, best option is to import the certificate of the ESB to cacerts.