Connect openedge client to SSL webservice

A

atopher1

New Member
Hello all,

I have a simple web service that returns a message. The web service is exposed via tomcat, on 3 ports:
- 8080 for cleartext
- 8443 for server side SSL (no client certificate required)
- 8445 for client/server SSL authentication

I can access the WSDL OK on all ports from a browser e.g.
Code: 
[URL="https://vpdev01:8445/mammoth/mammoth/wsdl?targetURI=urn:devnocall"]https://server:8445/webserv/webserv/wsdl?targetURI=urn:[/URL]myservice
(had to import the client certificate in Windows for port 8445 to work).

I imported the 8443 certificate into the Openedge certificate store and can connect and run procedures on the webservice OK.

BUT..... cannot get it to connect on port 8445. Have tried importing various versions of the certificate (file type pkcs12 ext .p12) with no luck. I suspect that this is where the error is. Code to connect and run is:

Code: 
lh-webserv:CONNECT(
    “-WSDL [URL="https://vpdev01:8445/mammoth/mammoth/wsdl?targetURI=urn:devnocall"]https://server:8445/webserv/webserv/wsdl?targetURI=urn:[/URL]myservice -nohostverify”).
run helloworldObj set lh-webprocedure on server lh-webservice.
RUN helloworld in lh-webprocedure (
    input "My Alert",   
    output lc-result,  
    output lc-output) no-error.
lh-webservice:disconnect().
delete object lh-webservice no-error.
The error is:
Code: 
Secure Socket Layer (SSL) failure.  error code 17426: SSL routines (9318).

Can anyone provide any assistance?

Thanks.

Openedge 10.2505
Tomcat 7 running on W2008r2
 
Have just read this......
The SSL client certificate is not supported by OpenEdge. You need use something like STunnel if the WebService you're calling requires the client to present it's certificate.
Click to expand...
from http://www.progresstalk.com/showthr...VICE-from-progress-using-ssl-and-certificates

And also this post explains
http://www.progresstalk.com/showthr...for-client-side-digital-certificates-with-SSL

So guess I need to use something like stunnel as a work around then?

What I'm trying to achieve is locking down a web service to a client that has the correct certificate.
 
I don't know whether it has changed with OpenEdge 11, but with OpenEdge 10 not one single product ( RDBMS, AppServer, run time client ) support the SSL client certificate. Therefore you can't access a Web Service from with the 4GL that requires the client to present it's client certificate to the server during the SSL handshake unless you "tunnel" the request through a third party product that does the SSL handshake and is capable of that. STunnel would be one of these third party products that is capable of doing just that.

When you build a Web Service with OpenEdge then the SSL handshake with the client is done either by the JSE ( TomCat for example ) or the Web Server. In that case on the server side no Progress product is involved in the SSL handshake with the client. The connection from the JSE via the WSA to the AppServer is a whole different story. There is no way you can forward the SSL client certificate to the AppServer and on the AppServer you have no means to access the HTTP request that might include additional header information containing, for example, the strong authenticated user identity.

That is the reason why don't use the WSA. Instead we build our Web Services in Java and connect to the AppServer using the Java Open Client. Basically it works without a fuzz and we are pretty happy with it. It enables us to do a full blown strong authentication and pass the user credentials as standard input parameter to the procedures running on the AppServer. The only weakness could be seen in the fact that in such a setup the AppServer must trust that the incoming request has been strongly authenticated in the first place. But that is okay for us and, to be honest, the Java Open Client is a real beast.

Heavy Regards, RealHeavyDude.
 
Glad I gave up then after a couple of hours! Ended up proving my client/server certificate config worked with a simple .net app accessing the web services on Tomcat. Worked pretty much out of the box with a bit of tinkering with the application configuration.

I think for our purposes this will suffice, all I am really interested in is SSL transport from the WWW to the tomcat endpoint, and also ensuring that only certain clients can access it (i.e. those who have a valid client certificate distributed distributed by us).

.....but you've got me thinking with the whole open client thing, but that is for another day :)

Thank, Chris
 
You must log in or register to reply here.
Back
Top