Can anyone suggest how we can use client certificate in soap request?
I have tried using -WSDL -sslAuth -sslKeyFile -sslKeyPwd -ssl -Service -Port parameters in the connect statement but while calling operation it gives fault error string with tag
<detail ...><ProblemHeaderQName...>a:Action</ProblemHeaderQName></detail>
To me seems like WS-A addressing is missing.. even though I am passing <was:To> in <soap:header> tag..
Can anyone suggest further how to proceed...
Hi Dheeraj.gupta
We have build a micro-service using nodejs / javascript to facilitate this.
Using OpenEdge for client certificates etc is a hard road. In our case, I couldn't find a solution with tech support, so we just build a microservice, which is hosted in the cloud / on premise. It serves as a proxy between OpenEdge and the "real" webservice we are trying to call.
Took us a few days, but now that we have it running it's very flexible. We can use a simple format to send calls from our ABL to the microservice. And let the microservice do the work in a language suited for the internet (Javascript).
To clarify. THe microsercice can call multiple WSDL's, we just add more WSDL's ("routes") to the service when needed.
The ABL just sends a bunch of JSON to the microservice, and the microservice converts it to XML, send the data, receives the response and replies in JSON.
Every "route" can have its own client certificates. This also enables us to make use of "personal" certificates, bound to a single user / PC, for every end-user of the system. Lifting some of the constraints created by over-enthusiastic security officers.
Based on your list of options, you may not be using the correct ones. Your list of options tells the CONNECT operation to retrieve the WSDL document without using either HTTP BASIC or TLS client certificate authentication, and then try to call the Web Service using TLS client certificate authentication using the default key-file and password. Did you make sure the default key-file is present in DLC/keys and has the expected password?
The CONNECT has two sets of TLS client certificate configuration options:
a) retrieve the WSDL: -WSDL -WSDLAuth ssl -WSDLKeyFile <dlc-keys/key-file> -WSDLKeyPwd <key-file-pwd>
b) call the Web Service: -SSLAuth ssl -SSLKeyFile <dlc-keys/key-file> -SSLKeyPwd <key-file-pwd> ...
If your options list is correct, and the default key-file is accessible, you would have to turn on the debug options for SSL/TLS connections in the ABL and see exactly why the connection was rejected. The debug output is pretty detailed, but generally provides better information for TLS connection problems than the SOAP error detail.
Hope this helps
1) I can access the wsdl document without using the -wsdlxxx options.. not sure why these parameters are used and if they should be used.. but instead of -sslxxx options when I tried with -wsdlxxx options, it gave the same result.
Can you please suggest how to turn on the debug options for SSL/TLS connections in ABL. I have generated that with the help of soap-fault object handle.
Finally got worked out but by using dotnet classes in progress procedure...
Below is the URL which shows it details how to consume soap service with client certificate..
docs.microsoft.com/.../transport-security-with-certificate-authentication
1) Created a new strong named DLL from wsdl exposed by 3rd party using the visual studio
2) registered the certificate in windows certificate store
3) registered the newly created DLL (in step 1) using gacutil.exe
4) created assemblies.xml file using progress assembly reference and place it in working directory or some other directory but then use -assemblies startup parameter
And then use the new DLL classes and methods like how we can use the standard dotnet classes and methods..