SSL error when connecting to web service

The answer is that the $DLC/certs directory must contain a file 7999be0d.0.   If $DLC/certs does not contain 7999be0d.0, you have not imported the correct certificates for the web server hosting the WSDL document.

The (9407) error is expected if you get the (9318) error.

I have that file in $dlc\certs folder. Still I have the same problem.

I have used this command:

certutil -import path_to_cert/certifcate.pem

What process did you follow to get the certificate 799be0d.0 into the $DLC/certs directory? The error is insisting that the file does not exist or its contents are invalid.

Hi there!

I have the same problem. Is there any decision of the problem?

I'm trying to connect to MS Exchange 2010 web services, using this code:

DEFINE VARIABLE hWebService AS HANDLE.

DEFINE VARIABLE errmsg AS CHARACTER NO-UNDO INIT "SERVER NOT CONNECTED~n".

DEFINE VARIABLE i AS INTEGER NO-UNDO.

    CREATE SERVER hWebService.

    hWebService:CONNECT("-WSDLUserid 'usr' -WSDLPassword 'pwd' -WSDL 'https://exchange-test/ews/Exchange.asmx?wsdl' ") NO-ERROR.

    IF NOT hWebService:CONNECTED() THEN DO:

        DO i = 1 TO ERROR-STATUS:NUM-MESSAGES:

            errmsg = errmsg + ERROR-STATUS:GET-MESSAGE(i) + '~n'.

        END.

        MESSAGE errmsg VIEW-AS ALERT-BOX ERROR.

        STOP.

    END.

    MESSAGE 'connected' VIEW-AS ALERT-BOX.

    hWebService:DISCONNECT().

    DELETE OBJECT hWebService.

I've got the following error messages:

Secure Socket Layer (SSL) failure. error code -54:  unable to get local issuer certificate: for 1573732e.0 in C:\Progress\OE102b\certs (9318)

Connection failure for host exchange-test port 443 transport HTTPS. (9407)

Error loading WSDL document  https://exchange-test/ews/Exchange.asmx?wsdl : Fatal Error: connect operation failed (WinSock reported error=0) (11748)

I've imported sertificate in my $DLC\certs folder using either

mkhashfile .pem

and

certutil -format PEM -import .pem

I've obtain .pem next ways:

- copy to file from Internet Explorer on my local machine;

- export from Mozzila on MS Exchange Server machine;

- export from mmc on MS Exchange Server machine.

Every time the same result.

Help, please! :-)

I'm using OE 10.2b on Windows XP Pro SP3 and MS Exchange server 2010 ver. 14.02.0283.003 on Windows Server 2008 R2 SP1

It appears that from the error you are still missing a certificate in the $DLC/certs directory. 

It is possible that you are connecting to a web server that uses a chain of certificates.  If that is the case, you may have to import multiple certificates into $DLC/certs using certutil.  The trick is to discover which one is missing.  Debugging a missing certificate can be somewhat complicated and I am not sure this forum is the right place to go into that process.  But you can start by ensuring that certutil -import created a file 1573732e.0.  AFter that you will have to debug the certificate validation process used in your ABL client.

Thank you, Michael, for the fast response!

Here is the sslc utility info obtained by the following command:

sslc s_client -connect 10.10.1.100/ews/Exchange.asmx?wsdl:443 -showcerts -CApath c:\Progress\OE102b\certs

That's the result:

Loading 'screen' into random state - done

CONNECTED(00000778)

depth=0 /CN=exchange-test

verify error:num=20:unable to get local issuer certificate

verify return:1

depth=0 /CN=exchange-test

verify error:num=21:unable to verify the first certificate

verify return:1

---

Certificate chain

0 s:/CN=exchange-test

   i:/CN=exchange-test

-----BEGIN CERTIFICATE-----

MIIDI.......................

MRYwF.......................

MTExN.......................

AQEBB.......................

Zqj2a.......................

3ETK+.......................

kGV/2.......................

+r2X2.......................

QrV8f.......................

VR0PA.......................

LXRlc.......................

MAAwD.......................

nhurN.......................

OKv3C.......................

GFpKr.......................

+yN14.......................

wurcv.......................

-----END CERTIFICATE-----

---

Server certificate

subject=/CN=exchange-test

issuer=/CN=exchange-test

---

No client certificate CA names sent

---

SSL handshake has read 958 bytes and written 444 bytes

---

New, TLSv1/SSLv3, Cipher is AES128-SHA

Server public key is 2048 bit

Compression: NONE

Expansion: NONE

SSL-Session:

    Protocol  : TLSv1

    Cipher    : AES128-SHA

    Session-ID: AF0100004..............................

    Session-ID-ctx:

    Master-Key: C39A667..................................................

    Key-Arg   : None

    Start Time: 1333696754

    Timeout   : 300 (sec)

    Verify return code: 21 (unable to verify the first certificate)

---

read:errno=10054

proenv>

Here is some certificate info viewed by Internet Explorer:

General tab:

This certificate is intended for the following purposes:

- Ensures the identity of a remote computer

- All issuance policies

Issued to: exchange-test

Issued by: exchange-test

Certification path tab:

exchange-test

Concerning the file 1573732e.0 - it is present in $DLC\certs directory and also the pem file (exchange-test.pem) is there. 

Is this enought to determine the problem?

Hallo, Michael!

Here is the command prompt for certutil -list command:

proenv>certutil -list 1573732e

Certificate store entry: 1573732e

Certificate:

subject= /CN=exchange-test

issuer= /CN=exchange-test

notBefore=Mar 21 11:41:00 2012 GMT

notAfter=Mar 21 11:41:00 2017 GMT

In the CONNECT method I use the host name like this:

hWebService:CONNECT("-WSDLUserid 'usr' -WSDLPassword 'pwd' -WSDL 'https://exchange-test/ews/Exchange.asmx?wsdl' ") NO-ERROR.

In my hosts file I have defined host like this:

10.10.1.100     exchange-test

I've tried this one:

hWebService:CONNECT("-WSDLUserid 'usr' -WSDLPassword 'pwd' -nohostverify -WSDL 'https://10.10.1.100/ews/Exchange.asmx?wsdl' ") NO-ERROR.

but the result is "not connected" and errors are the same.

Excuse me, but i can't understand to which startup options to add '-sslverify 1'. Please explain!

Thank you again for the fast reply! I appreciate your help very much! Thank you! :-)

Add "-sslverify 1" to the ABL session's startup parameters.  I was not very specific.

The SSL certificate verification gets the peer's dns name and looks for it in the server certificate's "CN" field.  So it should be looking for "exchange-test".

Adding "-sslverify 1" to ABL session startup parameters does not help. The errors are the same.

I'll chek certificates on server machine on monday.

Thank you Michael!

Have a nice weekend!  :-)

The last -best- idea is to turn on the SSL connection tracing.   Tons of ugly SSL detail about the certificate verification process.  If you can get the log information - do not post it here.  E-mail me.

Set the environment variable before you run your start the ABL test procedure that connects to the WebService...

   set SSLSYS_DEBUG_LOGGING=5 ; export SSLSYS_DEBUG_LOGGING

Hopefully this will tell us something useful.

Hi [mention:96ac66c56cc24edba29a9cf865c9c3f5:e9ed411860ed4f2ba0265705b8793d05],

I have the exact same issue with [mention:260ee19f89d648358b445b851991f967:e9ed411860ed4f2ba0265705b8793d05]. May I know if this issue have been resolved and I would like to know the solutions to it. Thank you.

Hello,

nborshukov has not responded to tell us whether they solved their problem or not, and I have had no private conversation with them outside this forum.   Based on the date of the last post, I am assuming their problem was resolved.

To recap: the two biggest errors people make is not having the right ROOT and/or intermediate CA certificates registered in the client's $DLC/certs with the certutil utility (including self-signed), and in creating a certificates without the server's legal DNS name in the certificate's CN subfield of the subject field.   Please check that you have met both of these requirements.

Hi [mention:96ac66c56cc24edba29a9cf865c9c3f5:e9ed411860ed4f2ba0265705b8793d05],

Thanks for your quick reply.

It seems to me that I have a certificate chain issue. I am using a self-signed certificate.

I wanted to connect my Progress client application to OE 10.2B AppServer through secured AIA (HTTPS) but encountered these error messages:

Secure Socket Layer (SSL) failure. error code -54: unable to get local issuer certificate: for 273e6043.0 in C:\PROGRESS\OE102B\certs (9318)

Connection failure for host ttl port 443 transport HTTPS. (9407)

Application server connect failure. (5468)

If connecting through HTTP is fine.

I further tested with the provided AIA Java servlet to test for HTTPS with success:

Aia1 OK

Connection Pool (numCurrentConnections=0, numTotalConnections=0)

This is my appsrvtt.d setup:

"busObj" "ttl" "" yes no "" "busObjXYZ" "A" "https://ttl/aia/Aia?AppService=busObjXYZ"

I ran sslc command to test my certificate:

proenv> sslc s_client -connect ttl:443 -showcerts -CApath c:\progress\oe102b\certs

My results:

I have imported the correct certificate into my progress "certs" folder.

Do you have any advice?

Meantime I'll find out how I can debug from a certificate chain.

Thanks in advance.

I tried adding "-sslverify 0" and "-sslverify 1" argument onto Progress client application with no success as referenced from http://knowledgebase.progress.com/articles/Article/P118642.

Tried http://knowledgebase.progress.com/articles/Article/P90739, with a different results, it looks positive:

Ran the Progress client, different error message this time:

Secure Socket Layer (SSL) failure. error code -55: CONNECT HostName: (ttl) does not match Certificate: (NONE) (9318)

Connection failure for host ttl port 443 transport HTTPS. (9407)

Application server connect failure. (5468)

Implemented "-nohostverify" argument from http://knowledgebase.progress.com/articles/Article/P128646 to the Progress client but still having the same error message.

After re-creating the SSL cert with the correct Common Name (CN) to "ttl", it works! But will require more testing.

Using self-signed certificates is OK for development and qa, and I am happy you found the magic key for how to create and configure using them.    

Thanks [mention:96ac66c56cc24edba29a9cf865c9c3f5:e9ed411860ed4f2ba0265705b8793d05] for your help!

Is it normal for Progress client application when connecting via the internet (HTTP/HTTPS) through Progress AIA to OpenEdge DB to be very slow?

My setup:

Progress Client (Compiled against OE10.2B) ---> HTTP/HTTPS ---> IIS 7 ---> mod_jk ---> Tomcat 7 (Progress AIA) ---> OE AppServer Enterprise ---> DB Enterprise DB (OE10.2B)

Need advise.

Thank you.

Yes, it is very normal for the client to run slower.   The simple fact that you are tunneling through HTTPS will make it slower.   Add the fact that you are adding hops for additional network servers when you use AIA.   Last, add the SSL authentication and cryptography.

The real question is how much slower, and to a certain degree that is under your control.   In your configuration you have an IIS 7 running in a Windows server, which most use cases do not, so that will make it slower that going directly to Tomcat.   The configuration of SSL can have a large impact on the network performance, based on the encryption and key exchange algorithms chosen.   The architecture of the client can also affect performance in an SSL use-case based on the frequency it makes connections to the server (SSL connections are very expensive).    SSL's cryptography is generally executed in software and is a CPU intensive operation, so your choice of OS and hardware can have an impact.

As you can see there are a number of variables that affect performance.   So you can understand that 'slower' is relative.  If you can, remove the IIS server.   Run Tomcat on a fast OS using high performance CPUs.  It can be complicated, but configure the SSL server to use faster data encryption algorithm.   Make long lifetime SSL (TCP) connections from the client to the server.   Test.

Hope this helps.

Hi [mention:96ac66c56cc24edba29a9cf865c9c3f5:e9ed411860ed4f2ba0265705b8793d05],

Thanks for your response.

Just to add more info to my previous post, the performance on both HTTP and HTTPS were unacceptable.

Upon further investigation, the bottleneck is indeed with the IIS which you have pointed out. The reason is due to JK Mod is not certified to be used with IIS 7 as stated in http://forums.iis.net/t/1166457.aspx?Slow+Performance+After+Connecting+Tomcat+With+IIS+7. Solution is to replace JK Mod with "Application Request Routing" (ARR).

With the new setup, I have tested HTTP from WAN network, performance have improved greatly, it is near on par with local LAN network. Will update back here once I have SSL setup.

Hope this helps.