Error creating SSL context (140A90F1:lib(20):func(169):reason(241))

1
votes

A single user at one of our locations is receiving "Error creating SSL context" when emailing at random points throughout the day. Once the error happens, they need to restart the program. The routine works for the rest of our (emailing) users.

The full error is:

Error creating SSL context.
error:140A90F1:lib(20):func(169):reason(241)

That error maps to "error:140A90F1:SSL routines: SSL_CTX_new: unable to load ssl2 md5 routines"

That gave me a bit more to go on, and I dug up some interesting results. Quite a few of the results are for different environments, but a strikingly similar problem was happening for a Delphi user at the legacy Embarcadero support forms (but for HTTP). Dave Nottage (TeamB) even chimes in at some point reporting that a client of his is experiencing this problem as well.

Remy goes into how you shouldn't use OpenSSL for SSLv2 or even SSLv3, and then the conversation drifted off into the version of DLLs being used, and then dropped off the cliff. As to the first part of the thread, my users are using Office365, the IdSMTP.UseTLS is set to utUseExplicitTLS, and the IdSMTP.AuthType is set to satDefault. The IOHandler (TIdSSLIOHandlerSocketOpenSSL) SSL method has been set to sslvTLSv1_2 with no luck. As for the second half of the thread, my user has received the latest Indy OpenSSL DLLs from here.

Over on the OpenSSL github a user is also experiencing the same problem, including the fact that it comes and goes. They have even updated their Indy library with no luck.

Is this an OpenSSL thing, Indy thing, Delphi thing or my thing? Based on the multiple results returned from Google, I can see it's a somewhat common problem across all development environments (including up to Delphi 10.1).

What can I do to debug this? I'm able to put private builds of the software down. Are there any hail-mary settings I can try?

1
delphiopensslindy10delphi-xe3
My client is still experiencing the same problem, however it happens only a few times a year. I note that reason 241 is "UNEXPECTED_MESSAGE" - not sure if that helps any – Dave Nottage
This might be a stretch, but one way to find out what your program is doing is to run Wireshark to capture the full TCP/SSL connection between the local end and the remote - being able to see what the client offers in terms of ciphers and TLS version, and what the server negotiates, might suggest a setting you need to change. – Steve Friedl
On most platforms, Indy uses OpenSSL dynamically via external DLLs. Is it possible that your main app is doing something, such as using Indy itself inside of a DLL, that would cause Indy to unload OpenSSL dynamically? Once OpenSSL has been unloaded, reloading it causes major problems. OpenSSL is not designed or intended to be unloaded until process termination (OpenSSL 1.1.x even goes to lengths to prevent unloading). – Remy Lebeau
Thanks for the response Remy, even after so long on SO. This ultimately turned out to be caused by using OpenSSL DLLs across my primary program and a secondary DLL. For anyone in the future who might be reading, see stackoverflow.com/questions/60401489/… – FLDelphi

1 Answers

0
votes

I had the same problem, but then used: 

libcrypto-1_1.dll + libssl-1_1.dll

instead of old:

libeay32.dll + ssleay32.dll

and problem vanished.