tags:

views:

454

answers:

1

I have a simple web service sitting on our internal network. I used SOAPUI to do a bit of testing, generated the service classes from the WSDL , and wrote some java code to access the service. All went as expected as I was able to create the service proxy classes and make calls. Pretty simple stuff. The only speed bump was getting java to trust the certificate from the machine providing the web service. That was not a technical problem, but rather my lack of experience with SSL based web services. Now onto my problem. I coded up a simple EJB service and deployed it into JBoss Application Server 4.3 and now get the following error in the code that previously worked.

12:21:50,235 WARN  [ServiceDelegateImpl] Cannot access wsdlURL: https://WS-Test/TestService/v2/TestService?wsdl

I can access the wsdl file from a web browser running on the same machine as the application server using the URL in the error message. I can also run the code that access the webservice outside of the application server on the same machine as the application server ( just not from within ). I am at a loss as to where to go from here. I turned on the debug logs in JBOSS and got nothing more than what I showed above. I have done some searching on the net and found the same error in some questions, but those questions had no answers. The web services classes where generated with JAX-WS 2.2 using the wsimport ant task and placed in a jar that is included in the ejb package. JBoss is deployed in RHEL 5.4. I posted this on the JBOSS community forum but have had no responses as of this writing.

+1  A: 

Having a look at ServiceDelegateImpl it tries to do:

InputStream is = wsdlURL.openStream();

where wsdlURL is a non-null URL. That means the trouble lies in the openStream(). I expect the problem to be with the https root certificate; I can imagine that JBoss has it's own store of acceptable root certificates somewhere, and that your root is not in there.

What I would do to test this is to deploy the service on a HTTP server, and make the wsdlURL a http URL. If that works, it's the SSL layer.

If it is the SSL layer, try to manually add a keyStore, by defining it on the command line, like in the answer to this SO question.

extraneon
Thanks for the suggestion. I will try to deploy the service via HTTP to rule out the SSL layer in JBoss. I had started running the server and my test client in verbose mode to see if I could see a difference in the classes/jars being loaded, but this seems like a more logical place to look. Will report back. Thanks again
Rob Goodwin
Yes the error is that fact that the JBoss does not trust web services machine. JBoss swallows the exception that gives the problem away. By trying to open the stream as you indicate above produces the following exception.javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested targetSo once I figure out how to properly have the JBoss server trust the web services server certificate, I will post that and mark this as answered
Rob Goodwin
@Rob Goodwin The SO question to which I linked should be able to answer that. In principle you can import trusted root certificates in that keystore for use by JBoss. You can of course also switch the SSL validator implementation and design it to accept anything at all, but that's kind of a hack :)
extraneon
@extraneon The problem was as you expected, JBoss was using its own certificate store (key and trust). So I specified it on the command line –Djavax.net… but did not know that that was being overridden in some other non-standard place by a different startup script. But by using the -Djavax.net.debug=ssl line in your suggested link the keystore it was using was logged. A simple find/grep and I was able to find the offending script. I added the server certificate of the web service I was wanting to call into this keystore and now I am good to go – Thanks for your suggestion.
Rob Goodwin
@Rob Goodwin Glad to hear you solved the problem. These things are not easy to find :) All hail to grep -r -H !
extraneon