Jump to content
Die Holländer

SSL not found when using idHttp in docker image

Recommended Posts

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 by Die Holländer

Share this post


Link to post
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.

Share this post


Link to post

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 by DelphiUdIT

Share this post


Link to post
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 by Remy Lebeau
  • Thanks 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×