SSL not found when using idHttp in docker image

[Die Holländer 45]

Maybe I started this thread in a wrong forum (Cross Platform), so I try it here to see if my problem can be solved.

I'm using Delphi 11.3. On a Docker Linux platform I really want to access HTTP servers coded in Delphi.

 

I've tried everything to use the indy components on Ubuntu running in a docker container and

on my Windows I have installed the wsl Ubuntu 18, the PAServer and all the libraries and that is running

fine with the HTTP components. I made a project that is connecting to a website and after login it fetches some data.

The Ubuntu version 18 is using OpenSSL 1.1.1  11 Sep 2018. I forced to use Ubuntu 18 because the

"official" latest Docker Pull is creating Ubuntu 22 and because it raises SSL errors I thought maybe the SSL library

is too new for the indy components for this Ubuntu version. (found some old info from Remy on the web about this)

 

To get an docker image that runs with Ubuntu 18 and the lastest PAServer (Delphi 11.3) I had to create my

own Dockerfile to build this image and this went ok, as far i can understand..

The Fire Monkey form is working well and I can make small projects that works also.

Only the indy components don't work in the docker container and always raises the

'Could not load SSL Library' message. I even tried to lower the SSL library in the docker

image to 1.0.x without luck.

 

I have no idea what the difference is between the local wsl linux and the image on docker.

Both the image on docker and the wsl Ubuntu on Windows are using Ubuntu 18 and OpenSSL 1.1.1  11 Sep 2018

and this local Ubuntu is working fine with the indy HTTP components.

 

Has anyone succeeded to run indy HTTP components in a docker container?

Any suggestions what I can try to do to let the components work in a linux-docker situation?

 

My previous thread:

 

Edited March 23, 2023 by Die Holländer

[Remy Lebeau 1392]

7 hours ago, Die Holländer said:

Only the indy components don't work in the docker container and always raises the

'Could not load SSL Library' message. I even tried to lower the SSL library in the docker

image to 1.0.x without luck.

What does Indy's IdSSLOpenSSLHeaders.WhichFailedToLoad() function return after the error has occurred?

7 hours ago, Die Holländer said:

Both the image on docker and the wsl Ubuntu on Windows are using Ubuntu 18 and OpenSSL 1.1.1  11 Sep 2018

and this local Ubuntu is working fine with the indy HTTP components.

Indy's default TIdSSLIOHandlerSocketOpenSSL component supports up to OpenSSL 1.0.2, it cannot use OpenSSL 1.1.x+, so you need to use this work-in-progress SSLIOHandler instead for newer OpenSSL versions.

[DelphiUdIT 172]

I never use a DOCKER, I always used normally operating surface and the only things that you need are the two .so libraries x Linux.

 

In one of my original projects, I used the standard Indy release with the Delphi, the libraries that I had are 1.0.2u (Linux 64 bit)  but the names exposed are:

 

libcrypto.so.1.0.0

libssl.so.1.0.0

 

I don't remember why (it happened 2 years ago) but i had also in the same directory the binary copy of the libraries with these names (and that i think was for Indy link);

 

libcrypto.so

libssl.so

 

If you have your Linux app, these libraries and optionally the .pem certificates you server must works. You don't need other things.

 

Bye

Edited March 23, 2023 by DelphiUdIT

[Remy Lebeau 1392]

2 hours ago, DelphiUdIT said:

In one of my original projects, I used the standard Indy release with the Delphi, the libraries that I had are 1.0.2u (Linux 64 bit)  but the names exposed are:

 

libcrypto.so.1.0.0

libssl.so.1.0.0

 

I don't remember why (it happened 2 years ago) but i had also in the same directory the binary copy of the libraries with these names (and that i think was for Indy link);

 

libcrypto.so

libssl.so

When loading OpenSSL, Indy checks for a whole list of different filenames, including the 4 you have shown above. The order in which that list is attempted can be influenced by setting Indy's CanLoadSymLinks and LoadSymLinksFirst settings before the libs are loaded.  By default, it will attempt to load the unversioned files first, so if that is problematic (because they map to a newer unsupported version of OpenSSL) then you should turn off the CanLoadSymLinks or LoadSymLinksFirst setting so the version-specific libs are attempted first/solely.  There are public IdOpenSSLSetCanLoadSymLinks() and IdOpenSSLSetLoadSymLinksFirst() functions in the IdSSLOpenSSLHeaders unit for that purpose. See https://www.indyproject.org/2018/05/04/changes-for-how-openssl-is-loaded-on-nix-platforms/

 

Edited March 23, 2023 by Remy Lebeau

[Die Holländer 45]

Remy, many thanks.

 

The IdOpenSSLSetCanLoadSymLinks() function set on false solved the problem.