Remote Services - via https

[Gavin Baumanis]

Hi Gang,

I think I have exhausted everyone for ideas over at CFAUSSIE so I
thopught I would visit here - just on the off-chance that my issue is
Galaxy releated - and not webservice(generic) related.

In order to create a remote service - I am using the following line;
<cfset remoteLoginService = createObject("component",
"loginService.loginServiceSampleApp.authUser.AppLoginService").init("http://
localhost/loginService/loginServiceSampleApp/vhosts/www/
loginService.cfc?wsdl")>

Which works on my localhost.

When I swap it to our staging server (and update the path
appropriately) and use https instead of plain http - I get the unable
to authenticate peer error - which according to Mr .Google and about 3
dozen blog entries - should be solved by importing the cert into the
java keystore.

But I have done this and can confirm the cert is in the keystore - but
still no dice.
I can also browse via Firefox to the URl and see the XML response (I
have the cert installed into my browser)


The reason for coming across to here is;

Is the CFC invocation correct for a remote service with Galaxy?

cflivedocs tells me that I should be invoking a webservice as;
createObject("webservice","http.........."

Which I tried but it failed with some obscure webservice error.

@195 or Service.cfc is;
<cfset webService = createObject("webservice", aWsdls[i])>

So I assume you're doing some rewriting there to get it into the
correct syntax.


Should be using something instead of;

<cfset remoteLoginService = createObject("component",
"loginService.loginServiceSampleApp.authUser.AppLoginService").init("http://
localhost/loginService/loginServiceSampleApp/vhosts/www/
loginService.cfc?wsdl")>

And I thought I would visit here to check on the off-chance that;
I was doing something wrong because I am using Galaxy,
Galaxy is unable to use https for remote services?

As always thanks in advance!


Gavin.

[Phil Haeusler]

Hi Gavin

I can't see there being anything Galaxy specific that would cause this -
i'm guessing it's a CF JVM ssl cert issue unfortunately as alluded to in
cfaussie.

Just as a test, can you try something along the following

<cfhttp method="get"
url="https://your-staging-service-that-isn't-working/loginService.cfc?wsdl">

i'd be interested knowing if the cfhttp works over ssl for you. I'm
sure the cert has been imported correctly, and yes i'm getting you to
double check that it's actually worked, but i can't see what else it
could be.

And in answer to your question, galaxy will take the WSDL url that you
pass to init() and then use it on that line 195. So essentially you're
doing exactly as the cf docs state, galaxy is just pushing the WSDL url
into your code, and calling the CreateObject("webservice") from its
internals.

Cheers
Phil

[Gavin Baumanis]

Hi Phil,

Thanks for the reply.
I have tried the cfhttp and that isn't working either.

Which pretty much leaves it as being a certificate error.
Which is what all the bogs and all the responses at the cfaussie
mailing list seem to be pointing towards too.

I juts can't for the life of me work it out.
I have not only restarted the CF service, but also the entire server.
The certifiate for the server AND the certificate used for signing the
server certifcate are both installed correctly in the keystore.
The certman plug in and also the commad line show the certifcates as
being in the keystore.
I have checked the path for the JRE used by CF and can confirm that
the commands used to insert and verify - were all used against the
same JRE.

It really has me stumped - oh well... I'll keep playing and see what I
can come up with.

Thanks again for the reply - I apreciate the assistance.

Gavin.

[Gavin Baumanis]

Well just to close this thread off;

I did in fact it getting to work successfully using a client cert and
ssl.

Basically I ust wasn't consuming the web service correctly.
To use SSL you must use CFHTTP - as this is the only tag that has the
client cert attributes.

Ultimately, we ended up removing the SSL requirement altogether for
this login service.
The login service and the application both run on the same secure
internal network - so SSL between servers wasn't really necessary and
contributed a lot of https/SSL overhead that wasn't necessary too.