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

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

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.

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

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

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.

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.

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

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..

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.

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.