Secure Socket Layer (SSL) failure. error code -54: unable t

Posted by David Abdala on 11-Oct-2016 10:27

Hello all,


I've been struggling with it a long time (I started a year ago, and once in a while I retake it), and still can't make an SSL connection from ABL to our secure server.

The last error I'm getting is:

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

After digging in documents and finally getting into this instruction:

chnServer:CONNECT('-sslprotocols TLSv1 -sslciphers AES128-SHA -ssl -nohostverify -H chonik.intranet  -S 443').

Without the sslprotocols, and sslciphers, the error is different (and even less informative). The server certificate gets imported with hash: 7bfe8dba by using certutil.

Running: sslc s_client -connect chonik.intranet:443

Loading 'screen' into random state - done
CONNECTED(0000015C)
depth=0 C = AR, ST = Mendoza, O = NomadeSoft, OU = Sistemas, CN = NomadeSoft, em
ailAddress = info@nomadesoft.com.ar
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = AR, ST = Mendoza, O = NomadeSoft, OU = Sistemas, CN = NomadeSoft, em
ailAddress = info@nomadesoft.com.ar
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = AR, ST = Mendoza, O = NomadeSoft, OU = Sistemas, CN = NomadeSoft, em
ailAddress = info@nomadesoft.com.ar
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=AR/ST=Mendoza/O=NomadeSoft/OU=Sistemas/CN=NomadeSoft/emailAddress=info@n
omadesoft.com.ar
   i:/C=AR/ST=Mendoza/L=Mendoza/O=NomadeSoft/OU=Sistemas/CN=Nomadesoft/emailAddr
ess=info@nomadesoft.com.ar
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDszCCAxygAwIBAgIBATANBgkqhkiG9w0BAQQFADCBlTELMAkGA1UEBhMCQVIx
EDAOBgNVBAgTB01lbmRvemExEDAOBgNVBAcTB01lbmRvemExEzARBgNVBAoTCk5v
bWFkZVNvZnQxETAPBgNVBAsTCFNpc3RlbWFzMRMwEQYDVQQDEwpOb21hZGVzb2Z0
MSUwIwYJKoZIhvcNAQkBFhZpbmZvQG5vbWFkZXNvZnQuY29tLmFyMB4XDTA4MDUw
MjE5MDYzOFoXDTE4MDQzMDE5MDYzOFowgYMxCzAJBgNVBAYTAkFSMRAwDgYDVQQI
EwdNZW5kb3phMRMwEQYDVQQKEwpOb21hZGVTb2Z0MREwDwYDVQQLEwhTaXN0ZW1h
czETMBEGA1UEAxMKTm9tYWRlU29mdDElMCMGCSqGSIb3DQEJARYWaW5mb0Bub21h
ZGVzb2Z0LmNvbS5hcjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA5aok4qme
0u1D9v2yBEpD9gThQja4bUaU3Va0ewN90LQgEpYKGIXJvC6z2qN14137WBvpDBSU
JdZGB0EPJMJxKZ7UEqvbq2/wro8pLM0QUtEwVIHIZcIuIqgtWsXsH/2fJ8KeyoXe
A65wfrfjhcyQatVDqFbGMS7s0xgKg3D5RUsCAwEAAaOCASEwggEdMAkGA1UdEwQC
MAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRl
MB0GA1UdDgQWBBQu1K1HTDQmQYjyYCwRJvuqxlWSkDCBwgYDVR0jBIG6MIG3gBQs
I+OLHllOtoe2IO1+XfmJjPHk4aGBm6SBmDCBlTELMAkGA1UEBhMCQVIxEDAOBgNV
BAgTB01lbmRvemExEDAOBgNVBAcTB01lbmRvemExEzARBgNVBAoTCk5vbWFkZVNv
ZnQxETAPBgNVBAsTCFNpc3RlbWFzMRMwEQYDVQQDEwpOb21hZGVzb2Z0MSUwIwYJ
KoZIhvcNAQkBFhZpbmZvQG5vbWFkZXNvZnQuY29tLmFyggEAMA0GCSqGSIb3DQEB
BAUAA4GBAC1GkOzmOsBeb91BwyBuVQVVUHw2QaKXCi43OnnYW8ZeuGknOmtcczXM
1VuO7OJuOgHSiyDkQhTBbaOn384QSeQccxRGV2PcURA83EnUbpygVi8Ay8blwZFg
lbnMtJ4/jeDQLmgppnLsxEg0cqE3N1oYsGevGum3+FIqN7FF9+6N
-----END CERTIFICATE-----
subject=/C=AR/ST=Mendoza/O=NomadeSoft/OU=Sistemas/CN=NomadeSoft/emailAddress=inf
o@nomadesoft.com.ar
issuer=/C=AR/ST=Mendoza/L=Mendoza/O=NomadeSoft/OU=Sistemas/CN=Nomadesoft/emailAd
dress=info@nomadesoft.com.ar
---
No client certificate CA names sent
---
SSL handshake has read 1522 bytes and written 495 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 5DAF2E1DE33A4559D08066DEDDBE2341D7A2CB87F2EA219095920BAC84C63ED8

    Session-ID-ctx:
    Master-Key: 43F242D928968E488C34BEBE35EBC5EDDFF471C39774037DB417E3774439A205
75DBABE4272455EF0425D03326447F0A
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1476199438
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---


I'm out of ideas, out of my field, out of patience, starting to badly speak about ABL.

Any help, idea, insult, will be appreciated.

Thanks.

David.

All Replies

Posted by Marco Mendoza on 11-Oct-2016 11:41

When I received this message "Secure Socket Layer (SSL) failure. error code -54:  unable to get local issuer certificate: for f454c2e0.0 in C:\Progress\OpenEdge\certs (9318)"  was because the certifcated was not installed, or the certicated changed I need to reinstall it or I installed the wrong cert (must be the very top certificate).

I recommend the knowledge ID: P183764 Title: "How to use GET method in HTTP request using SSL with socket connection from ABL?"   for the cert installation

Posted by David Abdala on 12-Oct-2016 05:42

Thanks,

I already followed that KB entry, and several others. Every method to import the certificate (which is a self signed one) shows 47ee430e.0 as the imported hash, but the error states ABL is looking for f454c2e0.0

I'm lost here, What is ABL looking for? there is no "certification path", the certificate is self-signed, so it is the certificate AND the CA.

Tried (again) several browsers (IE, Firefox, Chrome), all the available formats, with the same two results:

- Unable to import

- 47ee430e.0 imported

How do I get to know what certificate is ABL looking for as f454c2e0.0?

Why everything that connects to the server through https works, except ABL?

By the way, forgot to mention I'm using Progress 11.6 on Windows 7 x64

Had the same problem running 10.2B05 on Windows XP x32 (can't use it any more)

Thanks again.

David.

Posted by Brian K. Maher on 12-Oct-2016 06:05

David,

I'm not certain if the "server" is just a socket connection or a web service connection, but lets start from the top...

1) For the server you are trying to connect to, what SSL protocols does it accept for the connect process?  This would be one or more of SSLv3, TLSv1, TLSv1.1 and TLSv1.2.  This is important information to understand because we send the SSL "hello" message in whatever format you tell us to use.  If you don't specify anything we use the default which pre-11.6 would be SSLv3 and for 11.6 would be TLSv1.2.  If both sides are not using the same protocol for this "hello" exchange then you aren't going to get anywhere (i.e. it would be like two blind people trying communicate when one speaks urdu and the other one speaks latin, just not going to happen).  Search google using "site:knowledgebase.progress.com skipjack" and use the article which will come back to help you determine the protocols that are acceptable for the "hello" process.  The curl command is not part of Windows but I think you can download it (search google) or if you have access to a unix/linux box you can run the command from there.

2) Once you get the "hello" stuff resolved we then need to know what SSL protocols the server side allows for the post-connect communication.  The options are the same as in #1.  We need to know this so that you can specify what values we will support so that the negotiation between us and the server can come up with a mutually acceptable protocol to use.  If we cannot find one that both sides support then we will fail.  Note that when negotiating what protocol to use we go from most secure to least secure.

3) You need to ask whomever controls the server side for ALL of the certificates required to connect (there can be many .. i have seen up to 11 of them needed for some services).  Every required certificate MUST be imported into our certificate store (i.e. the %DLC%\certs directory using the certutil -import command from the proenv command line).

4) Find out if the server requires client side certificate support.  If so, for web services there some special parameters you need to use in the CONNECT() method.  See the documentation for details.  For a socket connection I believe you are out of luck but I am not 100% certain of that and need to do some checking.  If this is a web service and requires the client side certificate then the certificate goes into %DLC%\keys (I think) and not %DLC%\certs.

5) If you have not tried using the -nohostverify parameter in the CONNECT() method, do so.

The above is all I have to suggest for now.  Let me know the results, point by point, along with your code and we can move forward from there.

Brian

Posted by Brian K. Maher on 12-Oct-2016 06:11

David,

In reading your post from 6:42 AM this morning, the f454c2e0.0 file it is looking for means that there is a certificate chain (i.e. a chain of certificates .. more than one) that are required.  Step 3 from my post is something you MUST do to get this working.  Whomever controls that server has not provided you will all of the certificates.

Brian

Posted by David Abdala on 12-Oct-2016 06:21

Well.. I can confirm it has something to do with this particular server/certificate.

Created a self-signed certificate in another server, followed the same procedure to import it into ABL, but with this server/certificate, it works..

I guess will be easier to make some sort of redirection.

If anyone has any idea to find the problem, I'm willing to try out.

Posted by David Abdala on 12-Oct-2016 06:35

Hello Brian,

I'm just reading your post.

1) I'm using a plain SOCKET connection, with this connect statement:

chnServer:CONNECT('-sslprotocols TLSv1 -sslciphers AES128-SHA -ssl -nohostverify -H chonik.intranet  -S 443').

I think the "hello" part is Ok, but will check it with the KB you mention.

2) Guess is solved.

3) I have ALL the certificates, just one, self-signed. Have imported it in all the ways I've found in different KB entries.

4) No

5) I have

As you can see in a previous (well, guess it shows "latter") post, I've managed to connect to a different server with a single self-signed certificate. So it seems is a certificate problem.

Keep you posted.

Thanks.

Posted by Brian K. Maher on 12-Oct-2016 06:43

David,

Re #3 .. no, you don't have all the certificates.  You think you do but you don't.  Perhaps that is what is different between that server and the other one where only the self signed certificate works.

What are you actually connecting to on that server?  By this I mean ... IIS?  Tomcat? Some service you wrote in a language from Bob's grocery store and IT shop in nowhere, montana?

Brian

Posted by David Abdala on 12-Oct-2016 08:07

Brian,

followed the KB you pointed me to and verified I'm using the right protocol and cipher.  Also tried this openssl command, that returned the same information that I posted on the first post:

openssl s_client -showcerts -connect chonik.intranet:443

Using TSLv1 and SSLv3 I'm getting the same result: missing f454c2e0.0 certificate.

Using same protocol/cipher, connecting to a different server, works perfectly.

Running that openssl command in both servers, there is a significant difference, but I don't know the meaning:

Running server:

CONNECTED(00000003)

depth=0 C = AR, ST = Mendoza, L = Capital, O = Nomade Soft SRL, OU = TI, CN = yamana2, emailAddress = dabdala@nomadesoft.com.ar

verify error:num=18:self signed certificate

verify return:1

depth=0 C = AR, ST = Mendoza, L = Capital, O = Nomade Soft SRL, OU = TI, CN = yamana2, emailAddress = dabdala@nomadesoft.com.ar

verify return:1

[..]

Not running server:

CONNECTED(00000003)

depth=0 C = AR, ST = Mendoza, O = NomadeSoft, OU = Sistemas, CN = NomadeSoft, emailAddress = info@nomadesoft.com.ar

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

verify return:1

depth=0 C = AR, ST = Mendoza, O = NomadeSoft, OU = Sistemas, CN = NomadeSoft, emailAddress = info@nomadesoft.com.ar

verify error:num=27:certificate not trusted

verify return:1

depth=0 C = AR, ST = Mendoza, O = NomadeSoft, OU = Sistemas, CN = NomadeSoft, emailAddress = info@nomadesoft.com.ar

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

verify return:1

[..]

I'm looking into it, but nothing so far..

Posted by Brian K. Maher on 12-Oct-2016 08:15

David,
 
 
Brian

Posted by David Abdala on 12-Oct-2016 08:47

Nailed it!!

There is a problem with the certificate:

s:/C=AR/ST=Mendoza/O=NomadeSoft/OU=Sistemas/CN=NomadeSoft/emailAddress=info@nomadesoft.com.ar

i:/C=AR/ST=Mendoza/L=Mendoza/O=NomadeSoft/OU=Sistemas/CN=Nomadesoft/emailAddress=info@nomadesoft.com.ar

This two lines (subject and issuer) are expected to be the same, for self-signed certificates. In this case they don't match (the L is missing from subject). This is what makes ABL search for a certificate that doesn't exists, and the cause of the OpenSSL error 21.

You should check if this is an error or not (searching for a missing certificate), but for sure the certificate needs to be changed.

Thanks for all the pointers that lead me to find the problem.

David.

Posted by Brian K. Maher on 12-Oct-2016 08:56

David,
 
Great!
 
Glad you got it figured out.  I’ll check with development but I believe this is actually outside of our control.  This is OpenSSL doing what it needs to do to ensure correct security.  Assume that to be the answer unless I respond differently.
 
Brian

Posted by Brian K. Maher on 18-Oct-2016 13:58

David,
 
I checked with development and this behavior is what is expected and there is nothing we can do about it because this is what the PKI standards state must happen.
 
Cheers, Brian

Posted by David Abdala on 19-Oct-2016 05:52

Hi Brian,

thanks for the information. I've tried to add the "missing" certificate, but failed (honorably, of course).

So the only solution was to replace the certificate.

In the end, the best sequence to solve SSL issue was:

- openssl s_client -showcerts -connect <server>:<port>

this shows any problem with the certificate and the available chipers and protocols. Can be run from anywhere, including the problematic server. If there is any certificate problem, solve it or change the certificate.

The only "problem" that can be ignore is 18:self signed certificate.

- access server with any browser, export the certificate (choose PEM format if there is the option, .crt is PEM)

- proenv (on connecting endpoint)

- certutil -import <exported certificate> (on connecting endpoint)

- force the proper -chipers -protocols and -no-host-verify, if it's a self signed certificate, in the CONNECT string, if a simple CONNECT fails.

Done!, or change the certificate and try again..

Thanks for the help.

David.

This thread is closed