[Delphi 7 Indy 9 Could Not Load Ssl Library
Laurice Whack
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.
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 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.
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
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
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.
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.
> 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.
I recall having similar problems and in my case had to get the
then-current version of Indy (later than what was shipped with Delphi).
I know you said you failed to get the development snapshot but I think
you need to resolve that problem first.I'm successfully using the OpenSSL dlls with a version of 0.9.8.5--
-Mike (TeamB)
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...
Can you please turn on "Information messages" in HeidiSQL's preferences (tab "Logging"). Then, connect to some server which is working if you have one, then to the one which does not work. So the main window and the lower SQL log panel is visible at the time you are connecting to the pg server. That should give out some message in the log panel, saying
I have tried running HeidiSQL under the same setup as goffyara, but with 64-bit Ubuntu instead. Initially, I got the same "cannot find a usable libpq.dll" error. Then I tried running Heidi from the terminal by issuing:
That being said, ansgar, is it possible to make the error message more informative? LIBPQ library could not be loaded indeed, but it was because another dependent library was missing. It should be very easy to reproduce the situation under Windows, too.
r5146 tries to add the error message which Windows provides after failing to load libpq.dll (and/or libmysql.dll). Probably there is some useful information inside that message. I could however not reproduce the same here.
I have tried r5146, but I still get the generic "missing libpq.dll" message. Bad luck, I guess there would be no way to figure out the real error unless you actually check if msvcr120.dll is missing before loading the rest of the libraries.
Now that we have introduced the JSON Web Token in Part 1 and dissected it in Part 2, we are ready to fire up Delphi and start writing some code to generate, verify, and validate some JWT tokens.
Nearly all JWT's examples (even mines) use the word 'secret' as the secret key to sign the token but this is problematic because it is too short for the HS256 algorithm (or HS384 or HS512) so it's quite ineffective, in fact this can be quite dangerous from a security perspective.
The key for HMAC can be of any length (keys longer than B bytes are first hashed using H). However, less than L bytes is strongly discouraged as it would decrease the security strength of the function. Keys longer than L bytes are acceptable but the extra length would not significantly increase the function strength. (A longer key may be advisable if the randomness of the key is considered weak)
As you well know, the resulting JWT will be a base64-encoded string divided in 3 parts and signed with the specified key and signature algorithm. After that, you can take the token and (for example) send it to a REST client.
This is a full example that shows the construction of a JWT using the proper JOSE objects. Keep in mind that this is the powerful but "complex" way to build the JWT token but don't worry, the library exposes the TJOSE static class that greatly simplify the construction of the JWT token (we'll see it later).
The TJWT class represent the token (filled with the claims), the TJWK represent the key used to sign the token, the TJWS it's the class that does the signing, and the TJOSEAlgorithmId is the type (enum type) of the algorithm used, in short:
Now that we saw the "right" way to build a signed token (JWS) I can show you the TJOSE class that simplifies the process but, keep in mind, that if you need extra control over the creation of your token you can always use the native JOSE classes.
Obviously there are other utility methods such as SHA384CompactToken() and SHA512CompactToken() to cover other key lengths. The only caveat here is that using the SHA* methods the SkipKeyValidation property of the TJWS is always set to True.
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.
As you can see the most important thing to do when you receive a token is to verify it because if the signature has been forged or the payload has been tampered with you cannot trust the claims, therefore there is no point in validating them.
795a8134c1