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