Delphi 7 Indy 9 Could Not Load Ssl Library
Roseanne Gennett
After the error occurs, you can call Indy's WhichFailedToLoad() function in the IdSSLOpenSSLHeaders unit to find out WHY Indy wasn't able to load the SSL library. But most likely, you are simply using the wrong version of the DLLs. TIdSSLIOHandlerSocketOpenSSL supports only up to OpenSSL 1.0.2u, which you can get from Indy's OpenSSL Binaries repo on GitHub. If you want to use OpenSSL 1.1.x+ with Indy, you will have to use this SSLIOHandler instead (note: work-in-progress), or alternatively you can use sgcIndy.
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.
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 -Binaries for version 1.0.2 x64 (My app writing in 32bit and run on 64bit window 10)
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
You can use Indy's WhichFailedToLoad() function in the IdSSLOpenSSLHeaders unit to find out why Indy could not load OpenSSL. Either the DLLs could not be loaded in memory, or the DLLs are missing exports that Indy requires.
We use delphi 2007 for win 32 and the Indy components ver
10.1.5 (included in Delphi).
Whenever we try to establish a ssl connection by using the
tidhttp component with a tidsslopenhandlersocketopenssl
iohandler, we get an error, depending on the version of the installed
ssl dlls, the error is different. with the dlls in the binary
distribution of openssl.org (version 0.98 and 0.97) the error is
"could not load ssl library".With the version in the developer snapshot from atozed software, the
error is "cannot connect with ssl", and with the version we had
already installed from delphi 7 the error is "read timeout".Has anyone faced this problem and/or has a solution?
Is there a working demo somewhere on the Internet, that
we can download and see how it is working?
The demos provided from the developer snapshot, also present the same
errors. We try also to install the developer snapshot but we failed.
a) in the idglobal.pas it was a definition TthreadId that was
undefined. We change it to THandle, and we succeeded to compile all
the bpls but we failed to install the 2 dcl.. bpls because it couldn't
find some entry points in the ...system.bpl.Please because we want to transfer our programs from d7 with indy9 to
d2007 with indy 10, is there any one that can help us.Thanks in advance.
cannot say for sure but it seems to have something to do with d2007,
because d2006 and d7 does work ok with the openssl.org compiled library.
but the ssl libraries from atozed (if talking about those dated to
somewhere 2002) cannot be used with indy 10 at all.
i tested with d2007 too and when trying myself on same computer it
always fails, but on the server logs the clients were able to connect
using ssl - even i wasn't. anyway, as mentioned above already, d2006 it
worked ok on same computer also.maby re-install d2007 would do, by first not installing indy at all with
the installer and then later on only installing the latest snapshot?
this i haven't tested, but could help anyway.
use the build in delphi 2007 indy and the latest
installation of openssl from
it doesn't really matter if you are going to use the
"light" or "recommended for developers" version.create a form with a TIdHTTP (eg, name it http) and a
TIdSSLIOHandlerSocketOpenSSL component. assign the iohandler
of TIdHTTP to be TIdSSLIOHandlerSocketOpenSSL and set any
other parameters you might think you need. in your main program's
uses clause, put the "IdSSLOpenSSLHeaders" library to use.
in the event you want to trigger the ssl connection put the
following code: IdSSLOpenSSLHeaders.Load;
http.ReadTimeout:=0;
http.ConnectTimeout:=0;
showmessage(http.Get(' '));of course you can manage whether or not to load the ssl headers
from the action that the tidhttp is going to take (http or https)
and also the unload (IdSSLOpenSSLHeaders.unload) of the
ssl headers.hope this will help some people...
Antonis-Vassilis"Mike Williams (TeamB)" wrote in message
news:xn0fc3gvn...@newsgroups.borland.com...
Note, that Indy packages included in Delphi 6 and later distribution have package name "Indy.dpk". Indy packages, shipped with "standalone" (downloadable) versions of Indy have name Indy60 and Indy70 repsectively.If you are using such standalone package, you will need to open SSLBBoxSrvIndy* package (.dpk) file that you want to install and change the reference in "requires" clause from "indy" to "indy60" or "indy70" as needed.
Note, that Indy packages included in Delphi 6 and Delphi 7 distribution have package name "Indy.dpk". Indy packages, shipped with "standalone" (downloadable) versions of Indy have name Indy60 and Indy70 repsectively.If you are using such standalone package, you will need to open SSHBBoxSrvIndy* or IdSSHIndy* package (.dpk) file that you want to install and change the reference in "requires" clause from "indy" to "indy60" or "indy70" as needed.
Note, that Indy packages included in Delphi 6 and Delphi 7 distribution have package name "Indy.dpk". Indy packages, shipped with "standalone" (downloadable) versions of Indy have name Indy60 and Indy70 repsectively.If you are using such standalone package, you will need to open IdSFTPIndy* package (.dpk) file that you want to install and change the reference in "requires" clause from "indy" to "indy60" or "indy70" as needed.
The process of verifying a compact token is very simple using the delphi-jose-jwt library but before showing the code I want to clarify some (possible) confusion about the token verification and validation.
That said, the delphi-jose-jwt library contains some classes that greatly simplify the claims validation process. You can find the classes in the JOSE.Consumer.pas and JOSE.Consumer.Validators.pas units (more on this in the next article)
QuoteWilliam LaMartin wrote:
> How do I fix this? It seems to be a fairly common problem with these
> components, with the usual answer being to download the two DLL's. But I
> have obviously done this with the error message continuing.
Ensure the DLLs are in the Windows library path, eg in the System32
directory.
--
Dave Nottage (TeamB)
floor2_2(); William LaMarti Delphi Developer
Is it possible that it is being caused by some other part of the SSL setup
than the DLLs?
"Dave Nottage (TeamB)" wrote in message
news:3cdb2520_2@dnews...
Quote> William LaMartin wrote:
> > How do I fix this? It seems to be a fairly common problem with these
> > components, with the usual answer being to download the two DLL's. But
I
> > have obviously done this with the error message continuing.
> Ensure the DLLs are in the Windows library path, eg in the System32
> directory.
> --
> Dave Nottage (TeamB)
floor3_2(); William LaMarti Delphi Developer
Now the HTTPS post and receive is working perfectly.
Quote"William LaMartin" wrote in message
news:3cdb359b_1@dnews...
Quote> I have put the two DLLs in the C:\WINNT\system32 directory, but still get
> the error message.
> Is it possible that it is being caused by some other part of the SSL setup
> than the DLLs?
> "Dave Nottage (TeamB)" wrote in
message
> news:3cdb2520_2@dnews...
> > William LaMartin wrote:
> > > How do I fix this? It seems to be a fairly common problem with these
> > > components, with the usual answer being to download the two DLL's.
But
> I
> > > have obviously done this with the error message continuing.
> > Ensure the DLLs are in the Windows library path, eg in the System32
> > directory.
> > --
> > Dave Nottage (TeamB)
Patrick Dunfor Delphi Developer
That means Windows could not load that DLL into memory at all. Probably because it couldn't find the dependent ssleay32.dll file, but more likely because you mixed up the 32bit and 64bit versions of the DLLs. If your app is compiled as a 32bit EXE, you must use the 32bit version of both DLLs. If your app is compiled as a 64bit EXE, you must use the 64bit version of both DLLs.
ReportBuilder 21 utilizes the OpenSSL library to open and process the Digital Certificate file. While ReportBuilder includes the latest build of the OpenSSL library with its installation, it is highly recommended that you download* your own version to ensure the highest security. The Indy Project provides new builds daily at the following location:
e2b47a7662