Jump to content
JustinCase

Could not load OpenSSL library.

Recommended Posts

Keep trying to connect to a simple https site, but keep getting this error "Could not load OpenSSL library".

The DLL files are in my executable directory (libeay32.dll and ssleay32.dll). As far as I know, it is the correct version, though finding what OpenSSL version fits my installed Indy version does not seem easy and I may be wrong.

Downloaded the files from here: https://indy.fulgan.com/SSL/ 

My Indy version is 26.0.34749.6593

 

I also set a specific directory to look in, just in case:
  IdOpenSSLSetLibPath('C:\\Projects\\TestSSL\\Win32\\Debug\\');
  IdHTTP1.Get('https://www.vg.no');

 

Spent the whole day on this now, but solved the same issue in C# in under 5 minutes. Seems to be the way it is with Delphi these days.....

 

What am I doing wrong? Tried several proposed solutions online, but none of them work ('cause it can't even load the library).

Share this post


Link to post

Did you download the 32 bit version or the 64 bit ones?

The DLL bitness must match your programs bitness.

 

There shouldn't be any need to set the IdOpenSSLSetLibPath.

 

But if you want to set it, you can do it with:

Initialization
  IdOpenSSLSetLibPath(ExtractFilePath(Application.ExeName));

 

Share this post


Link to post
3 hours ago, JustinCase said:

Keep trying to connect to a simple https site, but keep getting this error "Could not load OpenSSL library".

When that error happens, you can then call Indy's WhichFailedToLoad() function in the IdSSLOpenSSLHeaders unit to find out WHY it failed.  Either the DLLs themselves could not be loaded into memory, or else they are missing exports that Indy requires.

3 hours ago, JustinCase said:

The DLL files are in my executable directory (libeay32.dll and ssleay32.dll). As far as I know, it is the correct version, though finding what OpenSSL version fits my installed Indy version does not seem easy and I may be wrong.

Indy supports up to the latest OpenSSL 1.0.2 DLLs.

3 hours ago, JustinCase said:

Downloaded the files from here: https://indy.fulgan.com/SSL/ 

Those DLLs are known to be working with Indy.

 

Share this post


Link to post

@Remy Lebeau

I upgraded to a new server (Win2008 to Win2019) and now I'm getting the same issue (trying to send eMail via Amazon SES).

 

This is inside an ISAPI 32bit dll that worked just fine when running under Windows 2008, but fails to send email when running under Windows 2019.

I literally use the same code, same DLLs as the Win2008 machine, all DLLs (my DLL & SSL) are 32bit, everything else in the code works fine except for sending eMail using TLS (SSL).

Inside IIS's application pool, the DLL is defined as 32bit, classic and "no managed code".

 

When calling "smtp.send" (TIdSMTP), I get the following exception and additional info:


3/22/2020 10:00:49 AM [       11854 ms] : SMTP Send Exception : SSL negotiation failed.

3/22/2020 10:00:49 AM [       11854 ms] : Inner Exception : Could not load SSL library.
3/22/2020 10:00:49 AM [       11855 ms] : WhichFailedToLoad : "Failed to load libeay32.dll."

 

The DLLs are in the same folder as the ISAPI DLL, I also tried placing them in the Windows/System32 folder but it made no difference.

Both "libeay32.dll" and "ssleay32.dll" are v1.0.2.19 and I'm using Delphi 10.3.3.

 

Edited by Yaron

Share this post


Link to post

I did further testing and it's also failing outside of IIS, when running as a normal process on my local Windows 10 machine (which I also recently upgraded from Windows 7 where the code worked fine).

 

So is this issue possibly specific to Windows 10/2019?

Edited by Yaron

Share this post


Link to post

I managed to debug the SSL DLL's LoadLibrary's GetLastError value and it's #193, which according to microsoft is "ERROR_BAD_EXE_FORMAT".

 

I don't belive the DLLs were corrupted, but just in case I downloaded the latest versions of the DLLs (v1.0.2.21) and no more errors on my local Win10 machine, but the Win2019 server is still triggering the same exceptions.

Edited by Yaron

Share this post


Link to post

Running the same code on the server, GetLastError returns #126 "ERROR_MOD_NOT_FOUND", however the OpenSSL DLLs are both in the same path as the running DLL and in the Windows/System32 folder.

Edited by Yaron

Share this post


Link to post

I placed another copy of the DLLs under "Windows/SysWow64" and now it seems to find the DLLs.

 

It would help debugging if calling "WhichFailedToLoad" or possibly the InnerException would return the GetLastError value from the LoadLibrary function.

  • Like 1

Share this post


Link to post
2 hours ago, Yaron said:

It would help debugging if calling "WhichFailedToLoad" or possibly the InnerException would return the GetLastError value from the LoadLibrary function.

Code has already been written to do exactly that, actually, but it hasn't been checked in yet.

Share this post


Link to post

I'm currently facing this kind of problem "Could not load OpenSSL library".
"WhichFailedToLoad" always returns "failed to load libeay32.dll" although I used "IdOpenSSLSetLibPath"
Using Delphi 10.2 with Indy 10.6.2.5366 and tried all DLL from 
https://github.com/IndySockets/OpenSSL-Binaries for version 1.0.2 x64 (My app writing in 32bit and run on 64bit window 10)

Share this post


Link to post
7 minutes ago, THANHNM said:

Using Delphi 10.2 with Indy 10.6.2.5366 and tried all DLL from https://github.com/IndySockets/OpenSSL-Binaries for version 1.0.2 x64 (My app writing in 32bit and run on 64bit window 10)

If your application is 32bit you also should use the 32 bit dll's. Not the x64 bit ones.

Putting them in your exe directory and not using IdOpenSSLSetLibPath should also work.

 

  • Thanks 1

Share this post


Link to post
1 hour ago, rvk said:

If your application is 32bit you also should use the 32 bit dll's. Not the x64 bit ones.

Putting them in your exe directory and not using IdOpenSSLSetLibPath should also work.

 

Oh tks, it's working now!
I thought the bit version is about the OS, didn't read the document carefully

Share this post


Link to post

Just encountered the same problem here. I have a working ISAPI / IIS config with Winserver 2012 r2 but running a new setup now.

Running an ISAPI 64bit application under a new Windows 2019 server. Placed the DLLs in the same folder as the app but still can't load it. 

 

@Yaron May I know which version of the DLLs did you used?

 

Update: placing in DLLs in SysWow64 seems to work

Edited by misc_bb

Share this post


Link to post

I just had to do a windows 10 upgrade in place because my windows update was stuck in January and wouldn't update. Now I'm getting eidosslcouldnotloadssllibrary could not load ssl. I'm assuming the ssleay.dll and libeay.dll were in the windows directory and got deleted with the upgrade? I'm working on an android app that indy was working just fine in but now it goes poof! Where should the files reside on windows development system? i put the copies in the embarcadero programs folder (C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\subversion) into Windows\SysWOW and Windows\System32 but it doesn't help. Delphi 11.2

Share this post


Link to post
45 minutes ago, Tim Clover said:

I just had to do a windows 10 upgrade in place because my windows update was stuck in January and wouldn't update. Now I'm getting eidosslcouldnotloadssllibrary could not load ssl.

And, what does WhichFailedToLoad() report, exactly?

45 minutes ago, Tim Clover said:

I'm assuming the ssleay.dll and libeay.dll were in the windows directory and got deleted with the upgrade?

OpenSSL has never come pre-installed in Windows, and 3rd party apps SHOULD NOT be installing OpenSSL into the Windows system folders.

45 minutes ago, Tim Clover said:

I'm working on an android app that indy was working just fine in but now it goes poof!

That has nothing to do with Windows.

45 minutes ago, Tim Clover said:

Where should the files reside on windows development system?

Best practice is for apps to install their own copy of OpenSSL in their own local installation folders.  You can get Indy-compatible versions of OpenSSL from https://github.com/IndySockets/OpenSSL-Binaries

45 minutes ago, Tim Clover said:

i put the copies in the embarcadero programs folder (C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\subversion) into Windows\SysWOW and Windows\System32

Please don't do that.  Also, the IDE is a 32bit app, and 32bit DLLs DO NOT belong in the 64bit System32 folder.

  • Like 1

Share this post


Link to post

Nevermind! I told rad studio to ignore the error as it was spurious in the android environment and everything works just fine. Reinstall of windows must have erased my previous instruction to ignore the error. Thanks Remy for the heads up on .dll locations, I'll remove them from Windows\SysWOW and Windows\System32

 

Tim Clover,

Cloversoft

Share this post


Link to post

I had the same issue on a new Windows 2016 build server with the openssl-1.0.2u dll in my application folder

Could not load SSL library.
WhichFailedToLoad: "Failed to load libeay32.dll."
GetLastError: 126 - "ERROR_MOD_NOT_FOUND"

Using ProcessMonitor I was able to find out that msvcp120.dll was not found on the host system,
so I had to install the latest "Visual Studio 2013 (VC++ 12.0)"
https://learn.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist?view=msvc-170#visual-studio-2013-vc-120

 

Share this post


Link to post
20 minutes ago, Stompie said:

I had the same issue on a new Windows 2016 build server with the openssl-1.0.2u dll in my application folder


Could not load SSL library.
WhichFailedToLoad: "Failed to load libeay32.dll."
GetLastError: 126 - "ERROR_MOD_NOT_FOUND"

Using ProcessMonitor I was able to find out that msvcp120.dll was not found on the host system,
so I had to install the latest "Visual Studio 2013 (VC++ 12.0)"
https://learn.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist?view=msvc-170#visual-studio-2013-vc-120

 

Where did you get the openssl-1.0.2u dlls from?

 

As I understand it there could be version with and without the dependencies to those Microsoft DLLs.

 

From https://wiki.openssl.org/index.php/Binaries (the indy.fulgan.com ones shouldn't have any dependency):

Quote

Pre-compiled Win32/64 libraries without external dependencies to the Microsoft Visual Studio Runtime DLLs, except for the system provided msvcrt.dll.

 

Share this post


Link to post
1 hour ago, rvk said:

Where did you get the openssl-1.0.2u dlls from?

 

As I understand it there could be version with and without the dependencies to those Microsoft DLLs.

 

From https://wiki.openssl.org/index.php/Binaries (the indy.fulgan.com ones shouldn't have any dependency):

 

If I remember correctly, I followed the instructions provided by Embarcadero: https://docwiki.embarcadero.com/RADStudio/Seattle/en/OpenSSL#32-bit_and_64-bit_Windows and I used option 1 to get the dlls, so they came from https://slproweb.com/products/Win32OpenSSL.html back when the 1.0.2 where available 

 

I replaced my dll's with the ones from https://github.com/IndySockets/OpenSSL-Binaries and those work without the dependency on "Visual Studio 2013 (VC++ 12.0)"

Share this post


Link to post
10 minutes ago, Stompie said:

If I remember correctly, I followed the instructions provided by Embarcadero: https://docwiki.embarcadero.com/RADStudio/Seattle/en/OpenSSL#32-bit_and_64-bit_Windows and I used option 1 to get the dlls, so they came from https://slproweb.com/products/Win32OpenSSL.html back when the 1.0.2 where available 

Yeah, I never used those from slprowen. They only provide an executable with god-knows-what build in.

 

Quote from this site https://wiki.overbyte.eu/wiki/index.php/ICS_Download

Quote

OpenSSL website also links to Win32OpenSSL website providing another build of Win32 DLL binaries. Note note that unlike the builds above builds on that site may have dependencies on Visual C++ 2008 Redistributables (to keep dll files smaller) so make sure you include all the required (and correct) redistributable files in your software installation. You probably don't have to care about that if you use binaries above at the cost of slightly larger DLLs. Also note that site does not keep archives of older versions so you may want to watch their page if you prefer their binaries.

 

The indy.fulgan.com ones (same as the one you now use) never gave me problems.

 

Share this post


Link to post
23 minutes ago, Remy Lebeau said:

Those are the same DLLs that used to be on the indy.fulgan.com site.

Except for a library for Android ARM64-V8 (64 bit) which is present in Indy and which is not present in Fulgan. :classic_biggrin:

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×