How to correctly make Indy TIdHttp use SSL libraries from a specific folder?

Question

I am successfully using Indy's TIdHttp (version 10 with Delphi 2009) to send data over https using the code below

var
  HttpClient: TIdHttp;
  IdSSLIOHandler: TIdSSLIOHandlerSocketOpenSSL;
  FormData : TIdMultiPartFormDataStream;

begin
  FormData := TIdMultiPartFormDataStream.Create;
  HttpClient:= TIdHttp.Create;
  IdSSLIOHandler:= TIdSSLIOHandlerSocketOpenSSL.Create;
  HttpClient.IOHandler := IdSSLIOHandler;
  ...
  <the rest of the code that uses HttpClient in the normal way> 
  ...

However this appears to only work if the SSL files libeay32.dll and ssleay32.dll are in the same folder as my exe. I need them to be loaded from a ProgramData sub folder instead.

If I copy libeay32.dll and ssleay32.dll from the exe's folder and place them in a folder C:\ProgramData\CommonData\ and then set the SSL path using IdOpenSSLSetLibPath (see below) the I get an error saying it cannot load the SLL libraries.

var
  HttpClient: TIdHttp;
  IdSSLIOHandler: TIdSSLIOHandlerSocketOpenSSL;
  FormData : TIdMultiPartFormDataStream;

begin
  FormData := TIdMultiPartFormDataStream.Create;
  HttpClient:= TIdHttp.Create;
  IdSSLIOHandler:= TIdSSLIOHandlerSocketOpenSSL.Create;
  IdOpenSSLSetLibPath('C:\ProgramData\CommonData');  //set path to libeay32.dll and  ssleay32.dll
  HttpClient.IOHandler := IdSSLIOHandler;
   ...
  <the rest of the code that uses HttpClient in the normal way> 
  ...

Using showmessage(whichfailedtoload ) in the exception handler seems to confirm that it is C:\ProgramData\CommonData\libeay32.dll that is the first to fail to load. So Indy is looking in the right place where it should find the identical file.

I don't know if I should call IdOpenSSLSetLibPath before or after creating HttpClient, or before or after assigning the IdSSLIOHandler but it doesn't seem to make much difference anyway.

I've checked these posts here and here and also a forum post here

Can anyone tell me why the identical SSL libraries load and work correctly when in the exe folder but not when they are in a ProgramData sub folder that is assigned using IdOpenSSLSetLibPath? - Better still how to make it work!

BTW I've even used a binary file comparison utility to ensure that the SSL files in the two locations are identical and also used PE to make sure that when it does work it is really using the DLLs in the exe folder and not from elsewhere.

score 0 · Answer 1 · answered May 26 '19 at 14:16

I believe I have might found the answer. The SSL files I had came from openssl-1.0.0j-win32-vc.zip. When I tried again using openssl-1.0.2r-i386-win32.zip, downloaded from https://indy.fulgan.com/SSL/ it worked correctly when the files were in the ProgramData sub folder. So it looks like the 1.0.0j files might have included some sort of dependency with other files that the 1.0.2r don't.

It isn't easy though, although the fulgan site for download is mentioned in some SO posts as if its obvious we are supposed to know about it, not all posts mention it and some just say 'get the latest' libraries. Trying to find out which are the latest and where they are is quite hard. Even the fulgan site has both 1.0.2r and 1.0.2q and there is no indication as to which is the latest (unless the letter is some sort of alphabetical version number)

"*So it looks like the 1.0.0j files might have included some sort of dependency with other files that the 1.0.2r don't.*" - use a Dependency Walker tool to verify that. Most OpenSSL distributions have a dependency on the MSVC++ runtime. The Fulgan distribution does not. "*unless the letter is some sort of alphabetical version number*"- it is exactly that, actually. — Remy Lebeau, May 29 '19 at 08:11

How to correctly make Indy TIdHttp use SSL libraries from a specific folder?

1 Answers1