curl does not work for https urls - /usr/lib64/libssl.so.1.0.0: version `OPENSSL_1.0.x' not found

English Applications
1

Hi,

on a fresh OpenSuse Leap 15.1 deployment the curl command line tools does not work with https urls:


i001385@wdf-lap-1443 ~> curl -vvv https://google.com
curl: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

So i thought, ok, maybe the rpm dependency is broken and additionally installed the libopenssl1_0_0 package.
Curl still does not work, but the error message changed:


i001385@wdf-lap-1443 ~> curl -vvv https://google.com
curl: /usr/lib64/libssl.so.1.0.0: version `OPENSSL_1.0.1' not found (required by curl)
curl: /usr/lib64/libssl.so.1.0.0: version `OPENSSL_1.0.2' not found (required by curl)

Here is a list of installed packages fur curl and openssl:


wdf-lap-1443:~ # zypper search --installed-only curl
Loading repository data...
Reading installed packages...

S  | Name           | Summary                                | Type
---+----------------+----------------------------------------+--------
i+ | curl           | A Tool for Transferring Data from URLs | package
i+ | libcurl4       | Version 4 of cURL shared library       | package
i+ | python3-pycurl | PycURL -- cURL library module          | package
wdf-lap-1443:~ # zypper search --installed-only openssl
Loading repository data...
Reading installed packages...

S  | Name              | Summary                                          | Type
---+-------------------+--------------------------------------------------+--------
i+ | libopenssl1_0_0   | Secure Sockets and Transport Layer Security      | package
i+ | libopenssl1_1     | Secure Sockets and Transport Layer Security      | package
i+ | openssl           | Secure Sockets and Transport Layer Security      | package
i+ | openssl-1_1       | Secure Sockets and Transport Layer Security      | package
i+ | python3-pyOpenSSL | Python wrapper module around the OpenSSL library | package

The curl package seems to be dynamically linked to the newer openssl version:


wdf-lap-1443:~ # ldd `which curl` | grep ssl
        libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x00007f05e941d000)

(Un)fortunately I am no C developer, I am living in the Java world where the CLASSPATH rules.

What can I do to resolve this problem?

Kind regards,

Michael

2

The first command is run as non-root the second as root. You cannot compare them. Apparently your user attempts to run some different binary than root.

3

****, your are right.

An other curl was picked up from the users PATH.
After setting the /usr/bin directory first the https download works


i001385@wdf-lap-1443 ~> set -x PATH /usr/bin $PATH
i001385@wdf-lap-1443 ~> which curl
/usr/bin/curl
i001385@wdf-lap-1443 ~> curl -vvv https://google.com
* Rebuilt URL to: https://google.com/
* Uses proxy env variable no_proxy == '.ci.dev.icw.int,.icw.int,.dev.icw.int,localhost,192.168.1.1/24'
* Uses proxy env variable https_proxy == 'http://localhost:3128/'
*   Trying ::1...
* TCP_NODELAY set
* connect to ::1 port 3128 failed: Connection refused
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 3128 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to google.com:443
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/7.60.0
> Proxy-Connection: Keep-Alive
> 
< HTTP/1.1 200 Connection established
< Connection: close
< 
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
....

Thank You.

4

That is the wrong solution! (I would not even call it a solution, but a way to make things worse).

You should always be fully loged in as root when doing things as root. Thus e.g. no

su

but always

su -