Palo Community Forum

I am trying to set up a Palo ETL connection using SOAP and https

I get an error like this (my emphasis):

Quoted

Error parsing wsdl file: WSDLException:
faultCode=OTHER_ERROR: Unable to resolve imported document at
'https://somewebservice.com/importData?wsdl'.: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target, please check the WSDL url in your browser.

Doing a generic google search this seems to be related to certificates in Java.
Before plunging into this, may be someone has checked it out already?

.

Have figured out that this is an issue with Java and what is needed is to import certificates to Java, but it has not resulted in a workable solution. (nor the manual method, nor InstallCerts).

Tested with Palo Commercial edition and I get a slightly different error (different machine)

Quoted

The component "SOAPtest" is tested with errors:

Error parsing wsdl file: WSDLException: faultCode=OTHER_ERROR: Unable to resolve imported document at 'https://somewebservice.com/importData?wsdl'.: java.net.SocketException: java.security.NoSuchAlgorithmException:
Error constructing implementation (algorithm: Default, provider: SunJSSE, class: com.sun.net.ssl.internal.ssl.DefaultSSLContextImpl), please check the WSDL url in your browser.

Has anyone ever succeeded to get SOAP over SSL working?

.

.
Bad news but thank you for the reply anyway. Took little bit less than a month to figure that out.

I guess the availability of SSL for http based connections is quite crucial (more broadly - Web Services, SOAP or not), especially for companies that use ESB solutions or want to integrate Palo with SaaS applications.

I am not a Java expert but looks like the ETL https capability is more of a configuration / enabling issue than something that needs heavy programming. So, should be a relatively quick fix.

.

.

Quoted

If you need to secure the web-based access to ETL, you can always install something like OpenVPN on the box PALO is running on and then do your connection through a VPN.

... only if the scenario were that the web service endpoint is under my control (having a VPN server or access there), which it isn't.

I guess this is just a minor mishap that support for _outgoing_ https requests are not supported. This is a de facto standard in this SaaSy world of ours. Plus, https is hassle free technology - when it is there, it just works. I would leave all other hacks aside, like a https proxy or using yet another ETL tool just because of the absence of outgoing https...

I just hope that there is nothing 'political' about this feature a la intent to keep Palo isolated from other SaaS based application, but I don't see no logical, business nor technological reasons for that.
.