"Could not load SSL library" and questions about Indy, Lazarus and Linux

[SlackerNReckless]

Hi

I'm not exactly new here as you can see but let's say I was out all this time.

Well, I compiled and I installed Indy not by the Online Package Manager, but it was here with added support for OpenSSL 1.1.1 and TLS 1.3 from the file "OpenSSL.zip" found here: https://github.com/IndySockets/Indy/pull/299

It works fine in Windows, all I need to do is just copy the four DLL files to the path of the program or copy them to system32 folder, you know, the DLL files libeay32.dll, ssleay32.dll, libcrypto-1_1.dll and libssl-1_1.dll

I use Slackware 15 and I installed the package "openssl-1.1.1m" and the libraries libssl.so and libcrypto.so are in the LD path, /usr/lib64/ but not the other two.

But I don't know how to do this in Linux. Where does the program find then? How do I load them? Do I need to link the executable with the libraries? How do I do that?

Anyway, thanks in advance for reading this and my best regards! 

P.S. I'm aware Remy Lebeau, Indy admin, is a member of this forum. It would be nice to receive a reply of him. 

[dbannon]

Slackware seems a little, er, slack, with new versions. 15 dates back to Feb 2022, more than 3 years ago ?

I suspect that openssl-1.1.1m is just  a bit too old to be honest.

You did not mention if your problem was as build (ie link) time or run time. But if you installed the libraries correctly then the OS will have no problem finding them. But 1.1.1 does not  support the protocols you must use today (a run time).

Davo

[SlackerNReckless]

Ok, I installed latest FPC 3.2.2 and Lazarus, 3.4. They were from SlackBuild packages as there are no official Lazarus packages for Slackware.

https://slackbuilds.org/repository/15.0/development/fpc/
https://slackbuilds.org/repository/15.0/development/lazarus/

I'm an old Slackware user and I'm a Delphi programmer, I have several Delphi apps, some use TIdHTTP and the SSL IO Handler TIdSSLIOHandlerSocketOpenSSL

And only recently I decided to move them to Lazarus, first in Windows then porting to Linux later.

Both FPC and Lazarus were installed and are working fine.

As a "Test" to see how the SSL would work I just made a simple test application.

Basically I added a TButton, a TMemo, a TidHTTP and the handler TIdSSLIOHandlerSocketOpenSSL. Of course I set up the IO Handler in TIdHTTP and tried to make a simple GET request

Code: Pascal  [Select][+][-]

1. procedure TForm1.Button1Click(Sender: TObject);
2. begin
3.   Memo1.Lines.Text := IdHTTP1.Get('https://www.google.com/');
4. end;

Doing the request without the "https" works.

I imagined it would find the SSL libraries in the path but all I get is a raised exception saying "Could not load SSL library". In Windows is simple, just put those 4 DLL files in the program path or windows/system32.

And like I said I have openssl 1.1.1m installed; It's a package that comes of Slackware Linux.

I would like to know where I put the SSL libraries and how they are loaded. I tried doing links of libssl.so and libcrypto.so in the program path but it didn't work.

Anyway, thanks for replying me.

[Jurassic Pork]

hello,
try this in a terminal console :

ldconfig -p | grep crypto
ldconfig -p | grep ssl

and show us what is the result.

Friendly, J.P

[SlackerNReckless]

Code: [Select]

root@SUCCUBUS:/# ldconfig -p | grep crypto
        libk5crypto.so.3 (libc6,x86-64) => /lib64/libk5crypto.so.3
        libk5crypto.so.3 (libc6,x86-64) => /usr/lib64/libk5crypto.so.3
        libk5crypto.so.3 (libc6) => /lib/libk5crypto.so.3
        libk5crypto.so.3 (libc6) => /usr/lib/libk5crypto.so.3
        libk5crypto.so (libc6,x86-64) => /usr/lib64/libk5crypto.so
        libk5crypto.so (libc6) => /usr/lib/libk5crypto.so
        libcryptopp.so.8 (libc6,x86-64) => /usr/lib64/libcryptopp.so.8
        libcryptopp.so (libc6,x86-64) => /usr/lib64/libcryptopp.so
        libcrypto.so.1.1 (libc6,x86-64) => /lib64/libcrypto.so.1.1
        libcrypto.so.1.1 (libc6,x86-64) => /usr/lib64/libcrypto.so.1.1
        libcrypto.so.1.1 (libc6) => /lib/libcrypto.so.1.1
        libcrypto.so.1.1 (libc6) => /usr/lib/libcrypto.so.1.1
        libcrypto.so.1 (libc6) => /lib/libcrypto.so.1
        libcrypto.so (libc6,x86-64) => /usr/lib64/libcrypto.so
        libcrypto.so (libc6) => /usr/lib/libcrypto.so
        libbd_crypto.so.2 (libc6,x86-64) => /usr/lib64/libbd_crypto.so.2
        libbd_crypto.so (libc6,x86-64) => /usr/lib64/libbd_crypto.so
root@SUCCUBUS:/# ldconfig -p | grep ssl
        libssl3.so (libc6,x86-64) => /usr/lib64/libssl3.so
        libssl3.so (libc6) => /usr/lib/libssl3.so
        libssl.so.1.1 (libc6,x86-64) => /lib64/libssl.so.1.1
        libssl.so.1.1 (libc6,x86-64) => /usr/lib64/libssl.so.1.1
        libssl.so.1.1 (libc6) => /lib/libssl.so.1.1
        libssl.so.1.1 (libc6) => /usr/lib/libssl.so.1.1
        libssl.so.1 (libc6) => /lib/libssl.so.1
        libssl.so (libc6,x86-64) => /usr/lib64/libssl.so
        libssl.so (libc6) => /usr/lib/libssl.so
        libgnutls-openssl.so.27 (libc6,x86-64) => /usr/lib64/libgnutls-openssl.so.27
        libgnutls-openssl.so.27 (libc6) => /usr/lib/libgnutls-openssl.so.27
        libgnutls-openssl.so (libc6,x86-64) => /usr/lib64/libgnutls-openssl.so
        libgnutls-openssl.so (libc6) => /usr/lib/libgnutls-openssl.so
        libevent_openssl-2.1.so.7 (libc6,x86-64) => /usr/lib64/libevent_openssl-2.1.so.7
root@SUCCUBUS:/#
I have "multilb" installed as I run WINE (Wine Is Not an Emulator) here hence the 32 bit libraries and the fact there are several 32 bits Windows applications..

Operating system is Slackware Linux 15 64 bits.

[Remy Lebeau]

Well, I compiled and I installed Indy not by the Online Package Manager, but it was here with added support for OpenSSL 1.1.1 and TLS 1.3 from the file "OpenSSL.zip" found here: https://github.com/IndySockets/Indy/pull/299

The code in the PR is an addon. You can install the main Indy code from OPM or GitHub first, then install the PR code on top of it.

It works fine in Windows, all I need to do is just copy the four DLL files to the path of the program or copy them to system32 folder, you know, the DLL files libeay32.dll, ssleay32.dll, libcrypto-1_1.dll and libssl-1_1.dll

There should be only 2 DLLs, not 4.  I think you are mixing different versions together. And *never* put the DLLs in the system32 folder, they don't belong there.

I use Slackware 15 and I installed the package "openssl-1.1.1m" and the libraries libssl.so and libcrypto.so are in the LD path, /usr/lib64/ but not the other two.

Sounds about right.

But I don't know how to do this in Linux. Where does the program find then? How do I load them? Do I need to link the executable with the libraries? How do I do that?

I'm not familiar with how the PR code works (part of the reason why the PR has been in limbo for so long), so I can't answer that right now.  I'll have to look at its loading code to see what it's doing.

P.S. I'm aware Remy Lebeau, Indy admin, is a member of this forum. It would be nice to receive a reply of him. 

Present and accounted for! 

I'm an old Slackware user and I'm a Delphi programmer, I have several Delphi apps, some use TIdHTTP and the SSL IO Handler TIdSSLIOHandlerSocketOpenSSL
...
I imagined it would find the SSL libraries in the path but all I get is a raised exception saying "Could not load SSL library"
...
And like I said I have openssl 1.1.1m installed;

When using TIdSSLIOHandlerSocketOpenSSL, you can use the WhichFailedToLoad() function to diagnose loading errors. But, that component does not support OpenSSL 1.1.1+, that is what the PR code is for, but it introduces a while slew of new SSLIOHandler classes, and offhand I don't know how to work with them.  IIRC, the author created separate SSLIOHandler classes for client-side vs server-side usage.

[dbannon]

Firstly, I know nothing about Indy, so, please disregard if you like !

You have both ssl(1) and ssl3 installed, that fine. But some issues -

• . Few eg websites will let you connect with the protocols used by ssl one. If you find one that does let you connect, might be a good idea not to...
• . Your libssl.so points (indirectly) to ssl one.

result : FPC322 does not know how to go directly to ssl3, instead, it looks to libssl.so which, as we noted, points to ssl one. That is because you have the dev package for ssl one installed. If you install the ssl three dev package (or just change the symlinks) it will work. A better approach would be to get the FPC 3.2.4 release candidate, compile it and use that instead.

Now, as I mentioned, I know nothing about Indy, it is quite likely it bypasses FPC322's dated use of SSL, if so, great !

Davo
 

[Remy Lebeau]

Now, as I mentioned, I know nothing about Indy, it is quite likely it bypasses FPC322's dated use of SSL, if so, great !

Yes, it does, as it does not use any SSL/TLS support in FPC at all, it loads and uses OpenSSL directly.

But the symlink issue is valid for Indy, at least for the older TIdSSLIOHandlerSocketOpenSSL component (again, I'm not sure how the newer PR code is setup to load libs).  By default, it loads the libssl and libcrypto libs, and if they are symlinks to a 1.1+ version then the load can fail.  You can use the IdOpenSSLSetCanLoadSymLinks() and/or IdOpenSSLSetLoadSymLinksFirst() function to avoid that problem so the component will load only pre-1.1 libs.

[SlackerNReckless]

Man... Mr. Lebeau replied me. Very cool, man! 

The code in the PR is an addon. You can install the main Indy code from OPM or GitHub first, then install the PR code on top of it.

Ok!

There should be only 2 DLLs, not 4.  I think you are mixing different versions together. And *never* put the DLLs in the system32 folder, they don't belong there.

Ok!

I'm not familiar with how the PR code works (part of the reason why the PR has been in limbo for so long), so I can't answer that right now.  I'll have to look at its loading code to see what it's doing.

Ok!

When using TIdSSLIOHandlerSocketOpenSSL, you can use the WhichFailedToLoad() function to diagnose loading errors. But, that component does not support OpenSSL 1.1.1+, that is what the PR code is for, but it introduces a while slew of new SSLIOHandler classes, and offhand I don't know how to work with them.  IIRC, the author created separate SSLIOHandler classes for client-side vs server-side usage.

Ok!

Anyway... I did another test here, I uninstalled the package, deleted all files and I installed the package "indylaz" from the Online Packages Manager, Indy version 10.6.3.2 without OpenSSL 1.1.1, the regular Indy you get, you know.

I tried my test program to see if it would work, but again, I got the same message. "Could not load SSL library".

I'm a bit lazy to check the Indy files how they load the libraries in Linux, well, I'm a slacker, hence my name Slacker N' Reckless! lol 

So I ask. Do I need to get the old OpenSSL 1.0.2? And install it? You know, from https://www.openssl.org/source/old/1.0.2/index.html But I need TLS 1.3 support.

By the way, I know about TFPHTTPClient . I did some tests and it works.

Probably I'll have to change my programs here from TIdHTTP to TFPHTTPClient, but I'm still wanting to use Indy as I intend to keep the original Delphi ones.

And I'm aware of this: https://www.esegece.com/products/sgcindy but they don't release the source and there isn't a Lazarus package. Looks like you need to pay for the source. And actually I already used this Indy, indeed it's the Indy with support for TLS 1.3 I use in my programs.

Okay, see ya!

[Remy Lebeau]

I tried my test program to see if it would work, but again, I got the same message. "Could not load SSL library".

And what did WhichFailedToLoad() say after the error occurred?

So I ask. Do I need to get the old OpenSSL 1.0.2? And install it? You know, from https://www.openssl.org/source/old/1.0.2/index.html But I need TLS 1.3 support.

The TIdSSLIOHandlerSocketOpenSSL component supports only up to OpenSSL 1.0.2 at this time, thus TLS 1.2.  For TLS 1.3, you'll need the PR code to use OpenSSL 1.1+

[Thaddy]

That said, TLS1.2 is still widely accepted and still supported by most if not all browsers.
But beginners still want to use SSL2/3/TLS1.0 and that is where the problems start.I have warned many times here and elsewhere against that misconception. OpenSSL supports TLS, no longer protocols with SSL in the name: they are simply no longer present in standard distributions.

This remark is not addressed to you, Remy, of course not, but to others that still don't get that message.

But not being able to not load the library is in most cases the wrong bitness or a very old OpenSSL. All information on how to load it properly and which version to use has been answered many times on this forum: it can only be caused by blindness.

More in general, other libraries that use OpenSLL now use: highest available first, fall-back till at most - bottom line - TLS1.1 and that will be removed soon. I guess that is likely no different from Indy. It is also no different from other mainstream libraries, all of them do not support SSL, only at most TLS1.1, many only higher.

[Remy Lebeau]

More in general, other libraries that use OpenSLL now use: highest available first, fall-back till at most - bottom line - TLS1.1 and that will be removed soon. I guess that is likely no different from Indy.

Unfortunately, no.  The TIdSSLIOHandlerSocketOpenSSL component still enables only TLS 1.0 by default (open ticket).  But you can turn on TLS 1.1 and 1.2 via its SSLOptions.SSLVersions property, and then it will negotiate the highest version with the peer.  I think the PR code defaults to TLS 1.2.

[SlackerNReckless]

And what did WhichFailedToLoad() say after the error occurred?

If you are saying about the function found in IdSSLOpenSSLHeaders.pas. Well, it returned nothing, a "blank" string.

I added another Memo and I just wrote this after the Get request above.

Code: Pascal  [Select][+][-]

1. Memo2.Lines.Text := WhichFailedToLoad;

The TIdSSLIOHandlerSocketOpenSSL component supports only up to OpenSSL 1.0.2 at this time, thus TLS 1.2.  For TLS 1.3, you'll need the PR code to use OpenSSL 1.1+

Understood! 

[SlackerNReckless]

Guys, I think I solved! 

As Slackware 15.0 comes with OpenSSL 1.1.1m I tried to install the old 1.0.2. Not available for Slackware 15, but for Slackware 14.2.

So I did another test here installing the old packages from 14.2 over 15. These packages.

openssl-1.0.2h-x86_64-1.txz
openssl-solibs-1.0.2h-x86_64-1.txz

But as I don't want to install old packages, I recompiled the old ones from 14.2 to use in 15, they are found here:
https://mirrors.slackware.com/slackware/slackware64-14.2/source/n/openssl/

And it's working now! With the old 1.0.2, of course! 

Now I need to see what I did wrong with that PR code, and use OpenSSL 1.1.1. It's like I said, I need TLS 1.3.

Otherwise I will use TFPHTTPClient, I did a test with a TLS 1.3 server here posting JSON data and it worked. 

[Thaddy]

TFPHTTPClient is the better choice anyway.