Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Error: Could not load SSL library
#1
Hi,

A small number of users report this error when trying to download webpages with my application.

The app includes recent versions of OpenSSL in the same folder as the exe.
I thought when loading a dll, the first place an app looks is in the same folder as the exe, so whether there are other copies of the dlls in other places or not, should not affect my application. However it seems that such things can have an effect. (see https://stackoverflow.com/questions/2504...i-xe2-iw14).

Is it possible for me to rename the dlls and then set a custom name for the dlls in Indy?

(Delphi XE4; Indy 5438)

Thanks
Rael
Reply
#2
Use a special directory for your SSL files, then force Indy to use this directory.
If you don't do this, Windows (?) will try to find the files anywhere on the system (using the global Path), and you may end up using some very old and dangerous versions, or incompatible ones.

Code:
uses IdSSLOpenSSLHeaders;

SSLDir := MyFullPath;
IdOpenSSLSetLibPath(SSLDir);


Bart
---
Bart Kindt
CEO and Developer
SARTrack Limited
New Zealand
www.sartrack.nz
Reply
#3
Can it not be in the same directory as the main exe with other files?
Reply
#4
(05-09-2018, 02:10 PM)RaelB Wrote: Can it not be in the same directory as the main exe with other files?

As long as you make sure that this is a guarantied permanent directory, e.g. you must enter is as an absolute path.
I always generate a subdirectory in AppData for my applications, and there keep all my internal application stuff.
Code:
procedure GetDataDirectory;
var
 Buffer: array [0..255] of Char;
begin
 FillChar(Buffer, 256, #0);
 try
   if SHGetFolderPath(Application.Handle, CSIDL_APPDATA, 0, 0, Buffer) = S_OK then
   begin
     DataPath := IncludeTrailingPathDelimiter(StrPas(Buffer));
     DataDir := IncludeTrailingPathDelimiter(DataPath + MyProgramName);
     if not DirectoryExists(DataDir) then ForceDirectories(DataDir);
     SSLDir := IncludeTrailingPathDelimiter(DataDir + 'SSL');
     if not DirectoryExists(SSLDir) then ForceDirectories(SSLDir);
 except
 //
 end;
end;

Nice and clean.
Above also still works under Windows XP.
---
Bart Kindt
CEO and Developer
SARTrack Limited
New Zealand
www.sartrack.nz
Reply
#5
I call this in Main Form initialization:

initialization
IdOpenSSLSetLibPath(ExtractFilePath(Application.ExeName));

Report from user:
Failed (using sslvTLSv1_2) for url: https://www.creativepegworks.com/
Error: EIdOSSLCouldNotLoadSSLLibrary, Could not load SSL library.
"Failed to load C:\Users\hjhu\Desktop\HttpsTestv1.2\libeay32.dll."
Failed (using sslvTLSv23) for url: https://www.creativepegworks.com/
Error: EIdOSSLCouldNotLoadSSLLibrary, Could not load SSL library.
"Failed to load C:\Users\hjhu\Desktop\HttpsTestv1.2\libeay32.dll."

"Failed to load..." is from call to WhichFailedToLoad()
This proves that Indy is looking for the correct dlls. However, the program still fails.
However, works fine for me on Windows 10.

http://www.bauerapps.com/dev/HttpsTest.zip

Any ideas?
Reply
#6
Honestly, read what it says.


Are you telling me that your executable is on the Desktop?
And you have set the SSL directory to where your executable is running from?
And where is that then?
And where did you copy your SSL files?

There are clearly NOT at "ExtractFilePath(Application.ExeName)" wherever that is.  Print it out and see if your libraries are actually there.


But: Stop using the 'executable' directory to put things in. This may be anywhere.  Use a Known, Fixed directory as I described, and you always know for sure where to find it, regardless if you run from the IDE of from wherever the executable may be at that time.

(If you run your program from the IDE, it runs from its compiled location, but if you use an installation package to install the program its somewhere totally different. So where are your libraries then?).

Bart
---
Bart Kindt
CEO and Developer
SARTrack Limited
New Zealand
www.sartrack.nz
Reply
#7
(05-09-2018, 08:49 AM)RaelB Wrote: Is it possible for me to rename the dlls and then set a custom name for the dlls in Indy?

The filenames are hard-coded in Indy's source code. Even if you renamed the DLLs and recompiled Indy, it still wouldn't work, because ssleay32.dll has dependencies on functions exported from libeay32.dll, so renaming that DLL would break those dependencies. You would have to recompile OpenSSL itself.

(05-09-2018, 03:19 PM)RaelB Wrote: Report from user:
Failed (using sslvTLSv1_2) for url: https://www.creativepegworks.com/
Error: EIdOSSLCouldNotLoadSSLLibrary, Could not load SSL library.
"Failed to load C:\Users\hjhu\Desktop\HttpsTestv1.2\libeay32.dll."
Failed (using sslvTLSv23) for url: https://www.creativepegworks.com/
Error: EIdOSSLCouldNotLoadSSLLibrary, Could not load SSL library.
"Failed to load C:\Users\hjhu\Desktop\HttpsTestv1.2\libeay32.dll."

"Failed to load..." is from call to WhichFailedToLoad()
This proves that Indy is looking for the correct dlls. However, the program still fails.
However, works fine for me on Windows 10.

http://www.bauerapps.com/dev/HttpsTest.zip

Any ideas?

Usually, when the DLLs themselves fail to load into memory, it is because they likely have dependencies on additional DLLs that are missing on the user's system, such as Microsoft's VC++ runtime DLLs. Try using the OpenSSL DLLs at http://indy.fulgan.com/SSL/, they don't have any extra dependencies (only to each other).

(05-09-2018, 01:54 PM)BartKindt Wrote: Use a special directory for your SSL files, then force Indy to use this directory.
If you don't do this, Windows (?) will try to find the files anywhere on the system (using the global Path), and you may end up using some very old and dangerous versions, or incompatible ones.

Windows doesn't look just anywhere, it has very specific places it looks for DLLs. If you don't use IdOpenSSLSetLibPath() to set a specific folder, you still have some control over where Windows looks, via SetDllDirectory(), AddDllDirectory(), and SetDefaultDllDirectories(). This is also important when dealing with OpenSSL DLLs that have external dependencies on other DLLs, because IdOpenSSLSetLibPath() does not influence where Windows looks for those other DLLs.

Reply
#8
>>Are you telling me that your executable is on the Desktop?

It looks like it, in a folder "HttpsTestv1.2"

>>And you have set the SSL directory to where your executable is running from?

Correct.

>>And where is that then?

C:\Users\hjhu\Desktop\HttpsTestv1.2\

>>And where did you copy your SSL files?

The zip file pointed to in previous post only contains 3 files.
HttpsTestXE4.exe
ssleay32.dll
libeay32.dll

>>There are clearly NOT at "ExtractFilePath(Application.ExeName)" wherever that is.

They clearly are...

>>But: Stop using the 'executable' directory to put things in. This may be anywhere.

And what is wrong with that? Are you familiar with "ExtractFilePath(Application.ExeName)"?

(05-09-2018, 06:19 PM)rlebeau Wrote: Usually, when the DLLs themselves fail to load into memory, it is because they likely have dependencies on additional DLLs that are missing on the user's system, such as Microsoft's VC++ runtime DLLs.  Try using the OpenSSL DLLs at http://indy.fulgan.com/SSL/, they don't have any extra dependencies (only to each other).
Thanks Remy.
I will give that a try
Reply
#9
Thank you. Using the fulgan DLLs has solved the problem.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)