pi 7.0, Soap receiver, https and proxy configuration...

[alejandro_sedanogonzlez]

Hi experts...

I have got a big problem with a RFC->Soap escenario. Maybe someone can help me...

I am trying to call a web service (https), without any authetication (no user-password and no client certificate) from a pi 7.0, through a proxy.

I have uploaded all the certificate tree of the service to the key store in the netweaver visual admin, and I am pretty sure that the java criptographic library has been deployed.

Calling the web service directly from my computer using SOAP-UI, works fine with the proxy settings...And with a browser from the pi server I am able to access the host of the service.

I have made some "Test cases" to see if I catch is he problem:

-Soap Receiver channel with the correct web service URL (https), and the proxy settings that works on the soap-ui:

It should works but it returns the "Connection closed from remote host"exception.

-Soap Receiver channel with the correct web service URL(https), but without any proxy settings:

I was expecting a "proxy authentication required" but I get the "Connection closed from remote host" exception.

-Soap Receiver channel with a wrong web service url (http), and with the correct proxy settings:

I was expecting a "not found" error, and i get a "Proxy authentication error".

-Soap Receiver channel with a wrong web service url (http), and without any proxy settings:

I get a "proxy authentication error", as expected...

¿Anyone knows which could be the problem?

Thanks in advance for your help.

[alejandro_sedanogonzlez]

Well,

It seems that the proxy uses NTLM authetication.... And the pi is not compatible with this kind of authentication...

I can not use AXIS, it is usefull to connect to NTLM authenticated web services, but the documentation says nothing about proxies....

[aashish_sinha]

HI Alejandro,

I am a bit confused here.

I am trying to call a web service (https), without any authetication (no user-password and no client certificate) from a pi 7.0, through a proxy.
I have uploaded all the certificate tree of the service to the key store in the netweaver visual admin, and I am pretty sure that the java criptographic library has been deployed.

Question here is when you are saying no client certificate what does it mean as you are uploading certificate tree in visual admin keystore.

You should upload client's certificate in Trusted Keystore in visual admin if you are not using user authentication.

Calling the web service directly from my computer using SOAP-UI, works fine with the proxy settings...And with a browser from the pi server I am able to access the host of the service

May be that webservice url is public. Hence you are able to post and test it from SOAP UI.

-Soap Receiver channel with the correct web service URL (https), and the proxy settings that works on the soap-ui:
It should works but it returns the "Connection closed from remote host"exception.

You should use correct webservice url only in SOAP URL. If it is HTTPS, install client certificate in your system. Error clearly suggest that from PI, you are not able to ping or telnet to destination system. Connectivity from your pi box to their system is not established. Donot use any proxy settings.

-Soap Receiver channel with the correct web service URL(https), but without any proxy settings:
I was expecting a "proxy authentication required" but I get the "Connection closed from remote host" exception.

Same as above. First step is to check connectivity between source and target system.

-Soap Receiver channel with a wrong web service url (http), and with the correct proxy settings:
I was expecting a "not found" error, and i get a "Proxy authentication error".

Wrong test case - Check above answers.

-Soap Receiver channel with a wrong web service url (http), and without any proxy settings:
I get a "proxy authentication error", as expected...

Check above.

Regards

Aashish Sinha

[alejandro_sedanogonzlez]

Hi and thanks for your answer Aashish...

To connect to a https service, or web, I think you need always a certificate issued by a trusted CA.

The idea is to guarantee the autenticity of the server identity.

The service is on the internet, with the correct proxy settings in a browser, I am able to download the wsdl in the pi server.

The problem is that those proxy settings does not seem to work in the channel.

I dont understand why in the pi machine I am able to acces to the service through a browser, but not through the pi comunication channel.

[aashish_sinha]

HI Alejandro,

That is the point actually. It will work from your browser with normal proxy settings but with same proxy settings it won't work, PI normally restricts IP's and you need to open it from PI to access those services in internet. First point is that try to ping/telnet or try trace-route from PI unix box and see if you are reaching to target server. If you are reaching, then you should be able to connect webservice from PI Comm Channel.

Thanks and Regards

Aashish Siha

[alejandro_sedanogonzlez]

Well, using the xpi inspector, I get the following trace:

Verify Remote SSL Server Certificate:

Client Certificates

<Client certificates uploaded>

server certificates

<Server certificates uploaded>

Using Transport Protocol: HTTPS

Trying to connect through the following proxy: proxy***********:****

ERROR on resolving proxy host. Proxy settings are ignored. Continue connecting without proxy

Exception Occured: Connection refused: connect

So the problem is the communication with the proxy system.

I use the same settings in the channel and in the browser....

I don't understand why it happens.

[Former Member]

Hi Alejandro!

Did you maintain the local hosts file on you PI System accordingly to reflect the Proxy's Server. E.g.

<Proxy ip address>     <Proxy Server Name as FQDN>

<Proxy ip address>     <Proxy Server Name just as Server name>

Regards,

Volker

[former_member190624]

Hi Alejandro,

Above error states that you did not maintained host entries (IP address and respective host name) in host file. Add host entry in host file , your error will be gone .

Thanks

Hari.

[Former Member]

Did you ignore my post or do you think double answerings are double helpful?

I do not like such kinds of copying ideas ... ;-(

[former_member190624]

Hello Volker,

It wasn't intentional. I open this thread long back  (Because page was not refreshed , I missed your comment on this thread ). After posting my reply , i realized that you already commented same and I am not able to delete my comment  from thread. Any way ,Please accept my apologies , If you feel i copied you idea .

Thanks

Hari.

[Former Member]

no problem .. had a hard week ... enjoy your weekend and we all cool down ... especialy me, okay? ... ;-))))))))

[alejandro_sedanogonzlez]

Hi Volker, and thanks for your help, but...

I have tried your solution and it does not work.

In fact, I also have tried using directly the ip address of the proxy in the comunication channel, but it does not work either.

And using the proxy's FQDN in the internet explorer in the server where the pi is installed allows me to access to the internet with the browser...

It is strange...

[Former Member]

Hello Volker,

Did you solve this problem?

Regards,

[alejandro_sedanogonzlez]

The only way we found to make this interface works, was to give the pi server access to the service without using the proxy server.

It seems that pi has problems with the NTLM authentication protocol wich is the one that uses our proxy server.

It is weird, NTLM is very common protocol.

[Former Member]

Hi Alejandro,

Here the problem was that somehow PI was trying to connect to the certificate chains URLs below and they were being blocked by the proxy. We’ve released these URLs and it started working .

CRL.microsoft.com/PKI/CRL/products/MicrosoftRootAuthority.CRL
www.microsoft.com/PKI/CRL/products/MicrosoftProductSecureCommunications.CRL
www.microsoft.com/PKI/CRL/products/MicrosoftProductSecureServer.CRL

Regards

Sergio