"Could not load SSL library" and questions about Indy, Lazarus and Linux lazarus / 38-Networking and Web Programming ---------------------------------------------------------------------- SlackerNReckless · 2024-07-21 21:31 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 · 2024-07-21 23:27 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 · 2024-07-22 00:25 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i procedure TForm1.Button1Click(Sender: TObject);begin  Memo1.Lines.Text := IdHTTP1.Get('https://www.google.com/');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 · 2024-07-22 00:57 hello, try this in a terminal console : Quoteldconfig -p | grep crypto ldconfig -p | grep ssland show us what is the result. Friendly, J.P ---------------------------------------------------------------------- SlackerNReckless · 2024-07-22 01:16 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 · 2024-07-22 07:31 Quote from: SlackerNReckless on July 21, 2024, 11:31:44 pmWell, 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. Quote from: SlackerNReckless on July 21, 2024, 11:31:44 pmIt 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. Quote from: SlackerNReckless on July 21, 2024, 11:31:44 pmI 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. Quote from: SlackerNReckless on July 21, 2024, 11:31:44 pm 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. Quote from: SlackerNReckless on July 21, 2024, 11:31:44 pmP.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!  Quote from: SlackerNReckless on July 22, 2024, 02:25:39 amI'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 · 2024-07-22 10:55 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 · 2024-07-22 15:59 Quote from: dbannon on July 22, 2024, 12:55:40 pmNow, 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 · 2024-07-23 20:01 Man... Mr. Lebeau replied me. Very cool, man!  Quote from: Remy Lebeau on July 22, 2024, 09:31:21 amThe 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! Quote from: Remy Lebeau on July 22, 2024, 09:31:21 amThere 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! Quote from: Remy Lebeau on July 22, 2024, 09:31:21 amI'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! Quote from: Remy Lebeau on July 22, 2024, 09:31:21 amWhen 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 · 2024-07-24 06:14 Quote from: SlackerNReckless on July 23, 2024, 10:01:27 pmI 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? Quote from: SlackerNReckless on July 23, 2024, 10:01:27 pmSo 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 · 2024-07-24 06:36 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 · 2024-07-24 15:41 Quote from: Thaddy on July 24, 2024, 08:36:04 amMore 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 · 2024-07-24 20:34 Quote from: Remy Lebeau on July 24, 2024, 08:14:17 amAnd 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Memo2.Lines.Text := WhichFailedToLoad; Quote from: Remy Lebeau on July 24, 2024, 08:14:17 amThe 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 · 2024-07-24 22:18 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 · 2024-07-25 10:21 TFPHTTPClient is the better choice anyway. ---------------------------------------------------------------------- Remy Lebeau · 2024-07-25 15:55 Quote from: SlackerNReckless on July 24, 2024, 10:34:53 pmIf you are saying about the function found in IdSSLOpenSSLHeaders.pas. Yes. Quote from: SlackerNReckless on July 24, 2024, 10:34:53 pmWell, it returned nothing, a "blank" string. That should not be possible after a "Could not load SSL library" error has occurred.  The loading process has a global list that stores the names of any libs that failed to load into memory, and any exports that failed to be found in the libs, and then WhichFailedToLoad() returns the content of that list.  The list is not cleared unless a new load process is attempted. ---------------------------------------------------------------------- SlackerNReckless · 2024-07-25 20:27 Quote from: Thaddy on July 25, 2024, 12:21:53 pmTFPHTTPClient is the better choice anyway. Yeah... And it's easy too. I learned it fast. Quote from: Remy Lebeau on July 25, 2024, 05:55:54 pmThat should not be possible after a "Could not load SSL library" error has occurred.  The loading process has a global list that stores the names of any libs that failed to load into memory, and any exports that failed to be found in the libs, and then WhichFailedToLoad() returns the content of that list.  The list is not cleared unless a new load process is attempted. Well, it's what was returned for me. An empty string. I took a look at the source code and I saw how the function works, by the way. I think you really need to update your Indy with support for OpenSSL 1.1.1 (and later) and TLS 1.3. Well, a lot of sites in the world already moved to TLS 1.3 and some are moving. Or otherwise your Indy will be very outdated and become useless. If you need people to test it just PM me here later. I'll be glad to help.  And thanks a lot, you, Mr Lebeau, for replying all these questions I asked here. I already spotted your name in other sites as well, always replying Indy related questions. Like StackOverflow and DelphiPraxis.Net See ya! ---------------------------------------------------------------------- Remy Lebeau · 2024-07-26 17:19 Quote from: SlackerNReckless on July 25, 2024, 10:27:05 pmI think you really need to update your Indy with support for OpenSSL 1.1.1 (and later) and TLS 1.3. I'm well aware of that.  Work on that feature has already been ongoing for awhile.