Calling Webservice With Wsdl File Throws Error

[greeshma]

Hi All,
I am trying to call an external wsdl url.
Sample code is given below. I am able to connect. But in second run (RUN ipAction IN hPortType), i am getting below error. Input is an XML. Expecting a xml having base64 data in one of the element in response xml which needs to converted to pdf file.

The error coming is : Secure Socket Layer (SSL) failure. error code 79: Unknown network error (9318) Connection failure for host tickeos.de port 443 transport HTTPS. (9407) Error sending Web Service Request: Fatal Error: connect operation failed (Error 0) (11767)

def var v-request-xml  as longchar no-undo.
def var v-response  as longchar no-undo.

CREATE SERVER hWS.
hWS:CONNECT( "-WSDL  https://wsdlurl   -WSDLUserid xxx    -WSDLPassword yyyy    -hostverify").
RUN ipPortype SET hPortType ON SERVER hWS.

/* Input xml and read output xml .
Expecting a xml having base64 data in one of the element in response xml which needs to converted to pdf file */
RUN ipAction IN hPortType ( INPUT v-request-xml, OUTPUT v-response ) no-error.

As per cert.client.log

[Fri Sep  4 14:38:24 2015] ID-0x132b4c10 CTX-0x132b6dd0 BIO-0x132b77d0 INFO  --- Attempting to write 254 bytes
[Fri Sep  4 14:38:24 2015] ID-0x132b4c10 CTX-0x132b6dd0 BIO-0x132b77d0 INFO  --- Wrote 254 bytes successfully
[Fri Sep  4 14:38:24 2015] ID-0x132b4c10 CTX-0x132b6dd0 BIO-0x132b77d0 INFO  --- Attempting to read 32768 bytes
[Fri Sep  4 14:38:24 2015] ID-0x132b4c10 CTX-0x132b6dd0 BIO-0x132b77d0 INFO  --- Read 519 bytes successfully
[Fri Sep  4 14:38:24 2015] ID-0x132b4c10 CTX-0x132b6dd0 BIO-0x132b77d0 INFO  --- Attempting to read 32768 bytes
[Fri Sep  4 14:38:24 2015] ID-0x132b4c10 CTX-0x132b6dd0 BIO-0x132b77d0 INFO  --- Read 6 bytes successfully
[Fri Sep  4 14:38:25 2015] ID-0x132b4c10 CTX-0x132b6dd0 BIO-0x132b77d0 INFO  --- Attempting to read 32768 bytes
[Fri Sep  4 14:38:25 2015] ID-0x132b4c10 CTX-0x132b6dd0 BIO-0x132b77d0 INFO  --- Read 16384 bytes successfully
[Fri Sep  4 14:38:25 2015] ID-0x132b4c10 CTX-0x132b6dd0 BIO-0x132b77d0 INFO  --- Attempting to read 32768 bytes
[Fri Sep  4 14:38:25 2015] ID-0x132b4c10 CTX-0x132b6dd0 BIO-0x132b77d0 INFO  --- Read 369 bytes successfully
[Fri Sep  4 14:38:25 2015] ID-0x132b4c10 CTX-0x132b6dd0 BIO-0x132b77d0 INFO  --- Attempting to read 32768 bytes
[Fri Sep  4 14:38:25 2015] ID-0x132b4c10 CTX-0x132b6dd0 BIO-0x132b77d0 INFO  --- Read 2 bytes successfully
[Fri Sep  4 14:38:25 2015] ID-0x132b4c10 CTX-0x132b6dd0 BIO-0x132b77d0 INFO  --- Attempting to read 32768 bytes
[Fri Sep  4 14:38:25 2015] ID-0x132b4c10 CTX-0x132b6dd0 BIO-0x132b77d0 INFO  --- Read 5 bytes successfully
[Fri Sep  4 14:38:26 2015] ID-0x13606630 CTX-0x00000000 BIO-0x00000000 INFO  --- Initialized OpenSSL client logging
[Fri Sep  4 14:38:26 2015] ID-0x13606630 CTX-0x00000000 BIO-0x00000000 INFO  --- Enabling SSL Client session reuse
[Fri Sep  4 14:38:26 2015] ID-0x13606630 CTX-0x13604e90 BIO-0x00000000 INFO  --- Terminated SSL Client session
[Fri Sep  4 14:38:26 2015] ID-0x132b4c10 CTX-0x132b6dd0 BIO-0x132b77d0 INFO  --- Terminated SSL Client session

 

[RealHeavyDude]

Since it is SSL the first question is whether you have imported the root certificate for tickeos.de in the Progress certificate store. Although you should get a different error in that case, the SLL handshake is a rather complex process. Therefore I would check this first.

If the root certificate is in the Progress certificate store then the next thing is to debug the SSL handshake. This KB article should get you started:
Progress KB - How to enable SSL debugging in OpenEdge?


Heavy Regards, RealHeavyDude.

 

[greeshma]

Since it is SSL the first question is whether you have imported the root certificate for tickeos.de in the Progress certificate store. Although you should get a different error in that case, the SLL handshake is a rather complex process. Therefore I would check this first.

If the root certificate is in the Progress certificate store then the next thing is to debug the SSL handshake. This KB article should get you started:
Progress KB - How to enable SSL debugging in OpenEdge?


Heavy Regards, RealHeavyDude.

Hi Dude,

We don't have any certification. Client advised us to use basic authentication.

Thanking you.

 

[RealHeavyDude]

Just to be clear: With any HTTPS a SSL handshake takes place. The basic SSL handshake includes the server presenting it's SSL server certificate to the client to prove its ( the server's ) identity. The client then uses the root certificate to cross check the SSL server certificate for validity. The client can only perform that check when it has access to the root certificate. For the ABL this means that the root certificate must be present in the certifcate store of Progress ( which is the folder $DLC/certs ). If it is not present the SSL handshake will fail.

This has nothing to do with client authentication. Client authentication can be implemented in the SSL handshake optionally ( the server reqeusting the client to present its SSL client certificate during the handshake which is then validated by the server to prove the client's identity ). Standard SSL does not include this. Therefore most client authentication relies on user name / password ( like in your case ) and is also called 1FA ( one factor authentication - something the client knows ) or weak authentication. Whereas 2FA ( two factor authentication - something the client knows and something the client has ) or strong authentication most likely involves a form SSL client certificate ( which could be located on a smartcard or some other device like an USB stick ).

In your case something seems to go wrong during the basic SSL handshake. The most common reason for the basic SSL handshake failing is that the client does not have access to the SSL root certificate matching the SSL certificate that is presented by the server. For the ABL this would mean that the root certificate is not found in the certificate store of the Progress installation.

Most web browser are able to download the root certificate in the background from the certificate authority without the user ever noticing. But the ABL does not do that. Therefore, most likely, the root certificate must be retrieved and imported manually.

Heavy Regards, RealHeavyDude.

 

[greeshma]

Just to be clear: With any HTTPS a SSL handshake takes place. The basic SSL handshake includes the server presenting it's SSL server certificate to the client to prove its ( the server's ) identity. The client then uses the root certificate to cross check the SSL server certificate for validity. The client can only perform that check when it has access to the root certificate. For the ABL this means that the root certificate must be present in the certifcate store of Progress ( which is the folder $DLC/certs ). If it is not present the SSL handshake will fail.

This has nothing to do with client authentication. Client authentication can be implemented in the SSL handshake optionally ( the server reqeusting the client to present its SSL client certificate during the handshake which is then validated by the server to prove the client's identity ). Standard SSL does not include this. Therefore most client authentication relies on user name / password ( like in your case ) and is also called 1FA ( one factor authentication - something the client knows ) or weak authentication. Whereas 2FA ( two factor authentication - something the client knows and something the client has ) or strong authentication most likely involves a form SSL client certificate ( which could be located on a smartcard or some other device like an USB stick ).

In your case something seems to go wrong during the basic SSL handshake. The most common reason for the basic SSL handshake failing is that the client does not have access to the SSL root certificate matching the SSL certificate that is presented by the server. For the ABL this would mean that the root certificate is not found in the certificate store of the Progress installation.

Most web browser are able to download the root certificate in the background from the certificate authority without the user ever noticing. But the ABL does not do that. Therefore, most likely, the root certificate must be retrieved and imported manually.

Heavy Regards, RealHeavyDude.

Thank you Dude
A wildcard certificate is used by the server . We had problems connecting initially and this was corrected by following the workaround mentioned in the below link.
Progress KB - OpenEdge client and bprowsdldoc are unable to connect to a site which uses wildcard certificates

The initial connection is working fine as per the initial messages in the SSL log
It is the second stage that looks to be throwing error.

 

[RealHeavyDude]

hWS:CONNECT( "-WSDL https://wsdlurl -WSDLUserid xxx -WSDLPassword yyyy -hostverify").

Just spotted that you use a connection parameter "-hostverify" - IMHO this should be "-nohostverify" instead.

Heavy Regards, RealHeavyDude.