Legacy Embarcadero Discussion Forums: SSL negotiation failed ...

Welcome, Guest: Login; Guest Settings

Thread: SSL negotiation failed

Reply to this Thread

Search Forum

Back to Thread List

	Replies: 7 - Last Post: Apr 10, 2017 11:43 AM Last Post By: Remy Lebeau (Te...

Patricio Cerda

Posts: 122
Registered: 3/13/01

SSL negotiation failed

Posted: Mar 31, 2017 3:49 PM

Hi,

I'm having troubles with the automatically email report that is working well on my development environment but not on other machines where I have installed the application.
This is the error message that I receive: "SSL negotiation failed." and happens on the following line:

smtpClient->Send(smtpMessage);

My environment is Win10 and C++Builder Berlin 10.1 Update 1.
I tested on four customers machines and it fails on all of them: Win10, Win8 and Win Server 2008.

Which could be failing?
Any help would be appreciated.

Best regards,
Patricio Cerda

Remy Lebeau (Te...

Posts: 9,447
Registered: 12/23/01

Re: SSL negotiation failed

Posted: Mar 31, 2017 5:24 PM

in response to: Patricio Cerda

Patricio wrote:

I'm having troubles with the automatically email report that is
working well on my development environment but not on other
machines where I have installed the application.

Did you have OpenSSL available on those machines? Did you verify that it
is getting loaded correctly?

This is the error message that I receive: "SSL negotiation failed."

That is a very generic error that Indy clients throw when an SSL/TLS handshake
fails. However, since you are using a modern C++Builder version, the exception
that is thrown (EIdTLSClientTLSHandShakeFailed) has an InnerException property
that should point to another Exception object (EIdOSSLCouldNotLoadSSLLibrary,
an EIdOpenSSLAPISSLError descendant, etc) containing more details about the
actual failure. The SSLIOHandler component also has OnStatus... events that
you can use to log some details while the SS/TLS handshake is in progress.

My environment is Win10 and C++Builder Berlin 10.1 Update 1. I tested
on four customers machines and it fails on all of them: Win10, Win8
and Win Server 2008.

Then it definately sounds like either you are not deploying/installing OpenSSL
correctly, or you are using an older version, or something like that. You
are very likely not using the same version that is on your development machine.

--
Remy Lebeau (TeamB)

Patricio Cerda

Posts: 122
Registered: 3/13/01

Re: SSL negotiation failed

Posted: Apr 1, 2017 4:17 PM

in response to: Remy Lebeau (Te...

Did you have OpenSSL available on those machines? Did you verify that it
is getting loaded correctly?

It wasn't installed. After I did a copy and paste of the files libeay32.dll and ssleay32.dll to the installation folder of my application, it works on one of the machines: Win Server 2008, but not on the other machines with Win10 (I double checked that those files are present on the installation folder of my application that is C:\Program Files\CINI-CSP\). The Win8 machine hasn't been tested yet.

The SSLIOHandler component also has OnStatus... events that
you can use to log some details while the SS/TLS handshake is in progress.

This event allowed me to see the following steps:
- Resolving hostname smtp.gmail.com
- Connecting to 64.233.186.108 or 64.233.190.109 or 64.233.186.109
- SSL negotiation failed

This doesn't help me understand what's happening, though.

Reviewing the files versions I found that:
- On my Win10 machine I have the 1.0.1.13 versions installed on the application folder and it works well, but if I change the files to the new 1.0.2.11 version then it does not work and shows the same error message
- On my Win Server 2008 machine the behavior is exactly the same
- On the customer's Win10 machine I had installed the 1.0.2.11 version, so I changed to the 1.0.1.13 version, but the error message is still there
- Can't test on other machines because they are still on production

This begs the question, why could this new version (.2.11) not work on my development machine while the previous one (.1.13) does? ...I would expect to use the latest one both in development and production, but it can't even work on my development workspace.

Regardless, the .1.13 version does work on my development machine, so what could be causing it not to work in the tested Win10 production environment?

Thanks in advance and best regards,
Patricio Cerda

Remy Lebeau (Te...

Posts: 9,447
Registered: 12/23/01

Re: SSL negotiation failed

Posted: Apr 3, 2017 2:41 PM in response to: Patricio Cerda

Patricio wrote:

After I did a copy and paste of the files libeay32.dll and ssleay32.dll
to the installation folder of my application, it works on one of the
machines: Win Server 2008, but not on the other machines with
Win10 (I double checked that those files are present on the
installation folder of my application that is C:\Program Files\CINI-CSP\).

Are you calling IdOpenSSLSetLibPath()? If not, try calling that at app startup,
eg:

IdOpenSSLSetLibPath(ExtractFilePath(Application->ExeName));

Or, you can alternatively call the Win32 API SetDllDirectory() or AddDllDirectory()
function:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms686203.aspx

https://msdn.microsoft.com/en-us/library/windows/desktop/hh310513.aspx

This event allowed me to see the following steps:

- Resolving hostname smtp.gmail.com
- Connecting to 64.233.186.108 or 64.233.190.109 or 64.233.186.109

Those messages are coming from the TIdSMTP::OnStatus event. Those are general
TCP messages. But what about the status messages coming from the TIdSSLIOHandlerSocketOpenSSL::OnStatus...
events? Those are OpenSSL specific status messages.

- On my Win10 machine I have the 1.0.1.13 versions installed on the
application folder and it works well

You really shouldn't be using 1.0.1 anymore, as it is no longer supported
by the OpenSSL developers. Use 1.0.2 instead (Indy does not support 1.1.0
yet).

but if I change the files to the new 1.0.2.11 version then it does not
work and shows the same error message

Works fine for me.

This begs the question, why could this new version (.2.11) not work on
my development machine while the previous one (.1.13) does?

I can't answer that, since I don't know what is going wrong on your machine.
Is it failing to find the DLLs at all? Is it failing to find specific exports
from the DLLs? Are the DLL exports simply failing when called? I need more
information. Does Indy's WhichFailedToLoad() function report any errors?
What does the call stack look like when the error occurs?

I would expect to use the latest one both in development and production,
but it can't even work on my development workspace.

Well, then you should be abl to debug it pretty easily until you find the
culprit.

--
Remy Lebeau (TeamB)

Patricio Cerda

Posts: 122
Registered: 3/13/01

Re: SSL negotiation failed

Posted: Apr 4, 2017 7:31 PM in response to: Remy Lebeau (Te...

Are you calling IdOpenSSLSetLibPath()? If not, try calling that at app startup,
eg:

IdOpenSSLSetLibPath(ExtractFilePath(Application->ExeName));

Ok, did it.

As I said, the described messages were generated by TIdSSLIOHandlerSocketOpenSSL::OnStatus. There is another event handler called TIdSSLIOHandlerSocketOpenSSL::OnStatusInfo that gives more detailed messages, but not on the machine that is failing.

You really shouldn't be using 1.0.1 anymore, as it is no longer supported
by the OpenSSL developers. Use 1.0.2 instead (Indy does not support 1.1.0
yet).

Ok, I will discard 1.0.1 and use 1.0.2 version.

Does Indy's WhichFailedToLoad() function report any errors?

Yes, it reports the following error: "Failed to load C:\Program Files (x86)\CINI CSP\libeay32.dll"

What does the call stack look like when the error occurs?

I don't know how I could obtain the call stack on the remote failing machine.

Does this new information help you to suggest me what could I do to solve this problem?

Best regards,
Patricio Cerda

Remy Lebeau (Te...

Posts: 9,447
Registered: 12/23/01

Re: SSL negotiation failed

Posted: Apr 5, 2017 8:34 AM

in response to: Patricio Cerda

Patricio wrote:

As I said, the described messages were generated by
TIdSSLIOHandlerSocketOpenSSL::OnStatus. There is another event
handler called TIdSSLIOHandlerSocketOpenSSL::OnStatusInfo that
gives more detailed messages

That is the one I was thinking of, sorry.

Does Indy's WhichFailedToLoad() function report any errors?

Yes, it reports the following error:
"Failed to load C:\Program Files (x86)\CINI CSP\libeay32.dll"

Well, there you go, then. One of the DLLs is failing to load into memory,
that is why the SSL/TLS handshake is failing. Make sure that:

- you are using matching ssleay32.dll and libeay32.dll for the same version
of OpenSSL.

- the two DLLs are in the same folder as each other.

- the two DLLs match the same bitness as your app. Since you app is in the
x86 folder, presumably it is a 32-bit app, so make sure the DLLs are also
32-bit.

--
Remy Lebeau (TeamB)

---
This email has been checked for viruses by AVG.
http://www.avg.com

Patricio Cerda

Posts: 122
Registered: 3/13/01

Re: SSL negotiation failed

Posted: Apr 8, 2017 5:22 PM

in response to: Remy Lebeau (Te...

Many thanks Remy!!!
Finally, I was able to get the email messages up and running with Indy and OpenSSL in all computers.

- the two DLLs match the same bitness as your app. Since you app is in the
x86 folder, presumably it is a 32-bit app, so make sure the DLLs are also
32-bit.

I think that this tip was what helped me to solve the problem, along with the WhichFailedToLoad() function that I did not know before.
To solve the problem, I deleted the libeay32.dll and ssleay32.dll from all folders where they were present: System32, SysWOW64 and from the installation folder of my application. Then I carefully took the 32 bit versions of these .dll's, because my application is compiled for 32 bits regardless of the destination PC and/or its operating system, and put them only in the installation folder. And that was it.

Best regards,
Patricio Cerda

Remy Lebeau (Te...

Posts: 9,447
Registered: 12/23/01

Re: SSL negotiation failed

Posted: Apr 10, 2017 11:43 AM

in response to: Patricio Cerda

Patricio wrote:

To solve the problem, I deleted the libeay32.dll and ssleay32.dll from
all folders where they were present: System32, SysWOW64

You should not have removed those copies, as they are likely placed there
by other apps.

Then I carefully took the 32 bit versions of these .dll's, _because my
application is compiled for 32 bits_ regardless of the destination PC
and/or its operating system, and put them only in the installation folder.

That is all you need.

--
Remy Lebeau (TeamB)

---
This email has been checked for viruses by AVG.
http://www.avg.com

Back to Thread List

Legend
	Helpful Answer (5 pts)
	Correct Answer (10 pts)

Developer Tools

Database Tools