CF11 Webservice over SSL

[Merchlinski]

I have a web service that I have working on our dev and test servers.  Now I'm trying to deploy it to production.  We have an external prod server in a DMZ that calls the web service on our internal prod server.  We only have port 443 open in the firewall between these two servers (not port 80).  I am able to do a <cfhttp> call to the WSDL over 443 and get back the xml.  I've even able to pass the method and parameters through the <cfhttp> call and get back the result I'm looking for:

<cfhttp method="get" url="https://app-int.phs.psu.edu/standard/date_function.cfc?WSDL&method=getNthDayOfMonth&dtMonth=#Now()#&...">

<cfdump var="#cfhttp#">

However, if I make the web service call using <cfinvoke> I get the following error:

<cfinvoke

webservice="https://app-int.phs.psu.edu/standard/date_function.cfc?WSDL"

method="getNthDayOfMonth"

returnvariable="dtMaintenance">

     <cfinvokeargument name="dtMonth" value="#Now()#" />

     <cfinvokeargument name="intDayOfWeek" value="1" />

     <cfinvokeargument name="intNth" value="4" />

</cfinvoke>

Cannot perform web service invocation getNthDayOfMonth.

The fault returned when invoking the web service operation is:

org.apache.axis2.AxisFault: Connection refused

        at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)

        at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:197)

        at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:75)

        at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(Common sHTTPTransportSender.java:402)

        at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSen der.java:231)

        at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:443)

        at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:406)

        at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java :229)

        at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)

        at standard.StandardDate_functionCfcStub.getNthDayOfMonth(StandardDate_functionCfcStub.java: 192)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorI... ''

I am able to successfully call the same web service (on the internal prod server) using the same code from my internal dev server.  However, when I look at my httpd logs on the internal prod server, I don't see the request in the ssl_access_log.  It shows up in the access_log file as:
150.231.26.130 - - [03/Feb/2015:13:48:57 -0500] "POST /standard/date_function.cfc HTTP/1.1" 200 397 "-" "Axis2"

Any thoughts why this appears to still be coming through port 80?

[Merchlinski]

Additional information:

When I view the WSDL - the endpoint URL is not generating with the s in https:

    <wsdl:service name="standard.date_function.cfc">

        <wsdl:port name="standard.date_function.cfcHttpsSoap11Endpoint" binding="ns:standard.date_function.cfcSoap11Binding">

            <soap:address location="http://app-dev.phs.psu.edu:443/standard/date_function.cfc"/>

        </wsdl:port>

        <wsdl:port name="standard.date_function.cfcHttpSoap11Endpoint" binding="ns:standard.date_function.cfcSoap11Binding">

            <soap:address location="http://app-dev.phs.psu.edu:80/standard/date_function.cfc"/>

        </wsdl:port>

        <wsdl:port name="standard.date_function.cfcHttpSoap12Endpoint" binding="ns:standard.date_function.cfcSoap12Binding">

            <soap12:address location="http://app-dev.phs.psu.edu:80/standard/date_function.cfc"/>

        </wsdl:port>

        <wsdl:port name="standard.date_function.cfcHttpsSoap12Endpoint" binding="ns:standard.date_function.cfcSoap12Binding">

            <soap12:address location="https://app-dev.phs.psu.edu:443/standard/date_function.cfc"/>

        </wsdl:port>

    </wsdl:service>

If I copy the xml into a file, make the change, push the file to the server, and change my invoke to use the file (rather than have CF generate the WSDL), it works.  I see the call show up in my ssl_access_log.

Working invoke:

<cfinvoke

webservice="https://app-int.phs.psu.edu/standard/date_function_web_int.WSDL"

method="getNthDayOfMonth"

returnvariable="dtMaintenance">

     <cfinvokeargument name="dtMonth" value="#Now()#" />

     <cfinvokeargument name="intDayOfWeek" value="1" />

     <cfinvokeargument name="intNth" value="4" />

</cfinvoke>

Is there a way to correct how the WSDL is generated so the endpoint URL incudes the https?

[BKBK]

A shot in the dark: have you installed the necessary certificate(s)?

[Merchlinski · Accepted solution]

Yes - the certificates were installed.

I've found a work around:

<cfset serviceDateFunction = createObject("webservice", "https://app-int.phs.psu.edu/standard/date_function_web_int.WSDL") />

<!--- Get the existing Endpoint URL to check the protocol.  --->
<cfset strEndpointURL = serviceDateFunction._getServiceClient().getOptions().getTo().getAddress() />

<!--- Update Enpoint URL.  --->

<cfset serviceDateFunction._getServiceClient().getOptions().getTo().setAddress("https://app-int.phs.psu.edu/standard/date_function_web_int.WSDL") />

[BKBK]

That got me wondering. Did you try the following alternative notation? If so, what was the result?

<cfset wsObject = createObject("webservice", "https://app-int.phs.psu.edu/standard/date_function.cfc?WSDL")>

<cfset dtMaintenance = wsOject.getNthDayOfMonth(dtMonth="#Now()#",intDayOfWeek=1,intNth=4)>

[Merchlinski]

No - that doesn't work.  It only works if I call setAddress().

As an FYI - I put the wrong URL into my last examples (if anyone else looks at this).  It should be https://app-int.phs.psu.edu/standard/date_function.cfc?WSDL") />

[BKBK]

Sorry, I don't understand where the setAddress() comes from. The suggestion in my last post is simply another way of writing the code in your original post. I just wondered whether createobject would do better than cfinvoke.

[Merchlinski]

I appreciate your time.  At least we have a work around!  Thanks!

[BKBK]

OK.The best of luck with the follow-up.

[Merchlinski]

I just recieved a notice that this is being included as a bug fix in CF11 Update 5.