openssl: error while loading shared libraries: libssl.so.3

Question

it doesn't matter what I type in combination with 'openssl', I always get the following error message:

'openssl: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory'

I have no idea how to fix that issue after reading many questions asked in this and in other forums.

Looks similar at your problem https://serverfault.com/questions/818445/error-while-loading-shared-libraries-libcrypto-so-1-1 — mkUltra, Jan 10 '19 at 08:59
Yes I have seen this before. But nevertheless looking at it twice helped me and I fixed my problem. Thanks. — M. L., Jan 10 '19 at 09:59

Eugene Lopatkin · Answer 1 · 2022-07-21T16:19:15.183

30

ldconfig /usr/local/lib64/

with compilation from sourecs:

./Configure
make
make install
ldconfig /usr/local/lib64/

You could add /usr/local/lib64/ path to your linker parmanently. In some linux distros it isn't added. Check this ansver

edited Jul 21 '22 at 16:19

answered Nov 08 '21 at 07:49

Eugene Lopatkin

2,351
1
22
34

1

Working solution, works perfect. Thank you Eugene! Now, time to read into ldconfig, as I only mildy know what it does. – Gareth Apr 19 '22 at 01:14
somehow it's not persistent for me. The error came again after reboot or logout – Ragtime Jul 21 '22 at 13:01
@Ragtime, meybe you should try to add /usr/local/lib64/ to your linker permanently? https://askubuntu.com/questions/334365/how-to-add-a-directory-to-linker-command-line-in-linux – Eugene Lopatkin Jul 21 '22 at 16:17
1

Thanks so much! I did `echo "/usr/local/lib64" > /etc/ld.so.conf.d/openssl.conf` after your command and it's now working perfectly! – Ragtime Jul 22 '22 at 04:03

score 14 · Accepted Answer · edited Dec 01 '20 at 15:18

14

I solved it that time only by creating a symlink and rebuilding the ldconfig cache.

ln -s libssl.so.3 libssl.so
sudo ldconfig

edited Dec 01 '20 at 15:18

jncraton

9,022
3
34
49

answered Feb 28 '20 at 10:29

M. L.

497
1
4
8

5

would be helpful if you can tell us the fully qualified paths to the .sos in your `ln` command; for me it was enough to just execute `sudo ldconfig` after compiling and installing openssl – woodz Feb 03 '22 at 22:54
1

I did this: # ln -s /usr/lib/x86_64-linux-gnu/libssl.so.3 /usr/local/lib64/libssl.so.3 and # ln -s /usr/local/lib64/libcrypto.so.3 /usr/lib/x86_64-linux-gnu/ (and then of course rebuild the cache with ldconfig) – wolf Mar 01 '22 at 14:53

score 10 · Answer 3 · answered May 05 '19 at 19:15

10

I had the same issue after installing Openssl 3.0. I resolved the issue by copying the files libcrypto.so.3, libcrypto.a and libssl.so.3 from /usr/local/lib to /usr/lib. After copying these files, you need to create some symbolic links.

ln -s libcrypto.so.3 libcrypto.so
ln -s libssl.so.3 libssl.so

Now rebuild the ldconfig cache:

sudo ldconfig

answered May 05 '19 at 19:15

Stofkn

1,428
16
24

4

This is dangerous advice, and should not be followed. Files in `/usr/lib` should be managed by your operating system's package manager -- overwriting them will leave your system in an inconsistent state. – May 05 '19 at 19:38
1

It is a dirty hack, but it worked on my Ubuntu 16. I compiled and installed the current openssl and curl (which uses openssl). I think when building Openssl there is an option you can pass to configure for the install path, to usr/lib in this case. – Rauli Kumpulainen Jun 02 '19 at 06:22
I had a similar error installing openssl from stratch: openssl: error while loading shared libraries: libssl.so.48: cannot open shared object file: No such file or directory. This trick worked for me. – Nick Dat Le Jun 05 '20 at 03:46

score 10 · Answer 4 · edited Mar 01 '22 at 22:36

I compiled openssl from github: https://github.com/openssl/openssl. Examining the Makefile generated (by ./config) the default install directory is /usr/local/lib64.

However, on RHEL, this directory is not in the load library path. The following worked for me on RHEL 7.9:

Edit ld.conf file to add a line containing /usr/local/lib64 :

$ sudo nano /etc/ld.so.conf.d/lib.conf
/usr/local/lib64

Sometimes, openssl is installed at /usr/local/ssl, and a file like /etc/ld.so.conf.d/openssl.conf is created. The path to libraries can be added here:

$ sudo nano /etc/ld.so.conf.d/openssl.conf
/usr/local/ssl/lib64

After adding the path to the file, update the library paths

$ sudo ldconfig

Sanity check

$ openssl version
Output: OpenSSL 3.0.0-alpha11 28 jan 2021 (Library: OpenSSL 3.0.0-alpha11 28 jan 2021)

on ubuntu i had to adjust the path in /etc/ld.so.conf.d/openssl-3.0.2.conf — Haselnussstrauch, Jul 19 '23 at 10:56
Thanks I added my installation path and it worked straightaway — Girish M, Aug 23 '23 at 03:02

score 3 · Answer 5 · answered Sep 01 '20 at 15:06

In my case it was related to Python 3.8 install on SLES 12.1. Pip install failed due to OpenSSL error.

Then I cloned the openssl repository and built it from source.

git clone https://github.com/openssl/openssl.git

./Configure make make install

Finally ldconfig is important and needed.

Then openssl version -a should show response without error. At least openssl 1.1 is needed to build Python 3.5+.

After this exercise the Python 3.8.5 build from the source was successful.

score 2 · Answer 6 · edited May 22 '19 at 06:03

2

Compile and run your code using sudo. It will work.

If it doesn't work then follow the below steps

sudo apt-get update
sudo apt-get install libssl1.0.0 libssl-dev
cd /lib/x86_64-linux-gnu
sudo ln -s libssl.so.1.0.0 libssl.so.10
sudo ln -s libcrypto.so.1.0.0 libcrypto.so.10

edited May 22 '19 at 06:03

Nima

3,309
6
27
44

answered May 22 '19 at 05:07

Sidhartha

29
3

score 2 · Answer 7 · edited Mar 05 '22 at 08:21

I initially had this issue on Fedora 22 (fc22.x86_64) (yes....old server). I was upgrading from an old version of OpenSSL (1.0.2) to OpenSSL 3.0.1. The following solution worked for me installing from the downloaded source openssl-3.0.1.tar.gz. I firstly uninstalled my previous version of OpenSSL which had not been installed from source, but rather DNF.

Uninstall previous version with DNF (OpenSSL 1.0.2)

dnf remove openssl openssl-devel

Install OpenSSL 3.0.1

$ cd /usr/src

$ tar zxvf openssl-3.0.1.tar.gz

$ cd /usr/src/openssl-3.0.1/

$ ./config

$ make

$ make install

$ ldconfig /usr/local/lib64/

$ openssl version

OpenSSL 3.0.1 14 Dec 2021 (Library: OpenSSL 3.0.1 14 Dec 2021)

score 1 · Answer 8 · answered Oct 24 '21 at 16:06

After installing openssl-3.0.0 i noticed that libssl.so.3 and libcrypto.so.3 files were located in /usr/local/ssl/lib64.

This worked for me :

I edited the openssl-X.y.z.conf file located in /etc/ld.so.conf.d/ and changed /usr/local/ssl/lib to /usr/local/ssl/lib64
I reloaded using ldconfig

Started runing these tow commands :

cd /etc/ld.so.conf.d/

sudo vim openssl-Z.y.z.config

Changed the file, saved it and exited from vim editor.

Ran

sudo ldconfig -v

I had output like :

#...
libssl3.so -> libssl3.so
#...

And make verification again

openssl version

My output:

OpenSSL 3.0.0 7 sep 2021 (Library: OpenSSL 3.0.0 7 sep 2021)

score 1 · Answer 9 · answered Nov 20 '21 at 19:34

1

On CentOS 7, for OpenSSL 3.0.0, this did the job for me

sudo ln -s /usr/local/lib64/libssl.so.3 /usr/lib64/libssl.so.3
sudo ln -s /usr/local/lib64/libcrypto.so.3 /usr/lib64/libcrypto.so.3

No system restart or ldcache config rebuild required.

answered Nov 20 '21 at 19:34

Dave

15,639
133
442
830

score 1 · Answer 10 · answered Nov 22 '22 at 11:45

1

Careful because if you upgrade on Manjaro you might destroy your system - Pacman and even Sudo rely on openssl-1.1, so you want to have the latest and the older both installed at the same time or you'll need to mount from a boot and repair.

answered Nov 22 '22 at 11:45

Michael Nolan

11
1

score 1 · Answer 11 · answered Mar 28 '23 at 16:34

In my case it was caused by some mamba/conda transaction, which has upgraded openssl to 3.0, version not present on the computer I did not have root to. When it is your situation calm down and simply downgrade

mamba install openssl=1.1.1t

or

conda install openssl=1.1.1t

score 0 · Answer 12 · answered Aug 07 '21 at 01:27

0

Just simple:

ln -s /usr/lib/vmware/lib/libssl.so.1.0.2/libssl.so.1.0.2 /usr/lib64/libssl.so.1.0.2
ln -s /usr/lib/vmware/lib/libcrypto.so.1.0.2/libcrypto.so.1.0.2 /usr/lib64/libcrypto.so.1.0.2

answered Aug 07 '21 at 01:27

vdTOG

23
1
6

score 0 · Answer 13 · answered Nov 22 '22 at 19:28

Faced the similar issue with the alpine based images upon running the upgrade command apk --no-cache -U -a upgrade

So, had to adjust the Dockerfile in the following way:

# syntax=docker/dockerfile:1

FROM nginx:alpine

RUN apk add --update openssl \
    && apk --no-cache -U -a upgrade

. . .

score 0 · Answer 14 · answered Dec 07 '22 at 06:59

0

Fixed this error by running: apt install libffi7

answered Dec 07 '22 at 06:59

Vishnu T

1
1

score 0 · Answer 15 · answered Mar 30 '23 at 05:44

For RedHat 7.9 after installing OpenSSL 3.1.0, I was able to see the version as root but not as regular user, so I sent this commands that finally helped me

$ sudo ln -s /usr/local/lib64/libssl.so.3 /usr/lib
$ sudo ln -s /usr/local/lib64/libcrypto.so.3 /usr/lib
$ sudo ldconfig
$ openssl version
OpenSSL 3.1.0 14 Mar 2023 (Library: OpenSSL 3.1.0 14 Mar 2023)

finally problem solved.

score -1 · Answer 16 · edited Dec 15 '21 at 11:48

This solution from kingaj (pasted below), also works for Ubuntu 20.04. I tested it and it worked perfectly:

"...I compiled openssl from github: https://github.com/openssl/openssl. Examining the Makefile generated (by ./config) the default install directory is /usr/local/lib64.

However, on RHEL, this directory is not in the load library path. The following worked for me on RHEL 7.9:..."

$ sudo touch /etc/ld.so.conf.d/lib.conf

# edit ld.conf file 
# add a line containing `/usr/local/lib64`
$ sudo nano /etc/ld.so.conf.d/lib.conf

# update the library paths
$ sudo ldconfig

# sanity check
$ openssl version
OpenSSL 3.0.0-alpha11 28 jan 2021 (Library: OpenSSL 3.0.0-alpha11 28 jan 2021)

openssl: error while loading shared libraries: libssl.so.3

16 Answers16