1

We have a java client (not a web app, just a simple batch written in Java) which has to connect to a web service over https. The Web Service lies in an Apache Tomcat Server (7.0) but I do not link directly to it because there is an IIS reverse proxy which exposes the service over https, so the certificates are in the IIS layer not in Tomcat. I notice something strange in the WSDL, i.e. the Service section still has an address like this

<soap:address location="http://myApp.it:80/Questionario/CallQuestionario"/>

as it does also the type section :

<xsd:schema>
<xsd:import namespace="http://www.test.it" schemaLocation="http://myApp:80/Questionario/CallQuestionario?xsd=1"/>
</xsd:schema>

I still see the location and schemaLocation pointing to an http not https! In fact I get an error when trying to connect to the Web Service: com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: java.net.ConnectException: Connection refused: connect

Do you think there is some work to do in the IIS layer to fix this problem? Even if I try to connect using Soap-UI I have this error: java.lang.Exception: Failed to load url; https://myApp.it:80/Questionario/CallQuestionario?wsdl, 0 - it looks like the analysis of the Web Service failed.

PS: Instead if I create a certificate for Tomcat using the keytool utility and I configure Tomcat editing the server.xml file I notice that, without changing the code of the service, the section gets automaticly updated with the url value in https both in service and type section. In this case (Web Service deployed on Tomcat in https) , after importing the certificate in the client using the following lines of code

    System.setProperty("javax.net.ssl.trustStore", "[PATH_TO_THE_CERTIFICATE]");
System.setProperty("javax.net.ssl.trustStorePassword", "[PWD]");
System.setProperty("javax.net.ssl.trustStoreType", "JKS");

everything works as it is expected to .

csciandr
  • 132
  • 1
  • 2
  • 14

1 Answers1

1

This is as expected. IIS is essentially acting as a proxy pointing to Tomcat, so Tomcat has no idea about IIS. Tomcat is only exposing over HTTP as the connection into IIS maybe HTTPS, but from IIS to Tomcat it's over HTTP.

The only option is to have IIS talking to a HTTPS Tomcat, so the WSDL gets generated correctly and shows ports 8443 (default Tomcat HTTPS) in the WSDL so when clients try to connect. Most clients though will allow you to override the port location in the WSDL description and enter your own, so you could tell your WSDL consumers this is what they must do.

David
  • 19,577
  • 28
  • 108
  • 128
  • Thanks a lot for yout reply, sorry but I have a question now, how can a java client written with jax-ws communicate to this web service, without changing the tomcat configuration? Is there a way to override the port location? – csciandr Feb 03 '14 at 10:28
  • Yeah there is, check out this answer http://stackoverflow.com/questions/5158537/jaxws-how-to-change-the-endpoint-address you just do the same thing but with the port. – David Feb 03 '14 at 10:44
  • Ok, flag ticked! I noticed that now even if I comment the System.setProperty settings it still works, isn'it a little bit strange, how can the client do the cipher stuff to the https connection without using the public key? Maybe I am missing something, anyway now it works! – csciandr Feb 03 '14 at 11:37
  • Hmm, I know what you mean but I'm not sure I can give you a confident answer. If I were you, try using a HTTP sniffer to listen to the message and see if it's encrypted, if you really want to be sure. – David Feb 05 '14 at 12:32