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 answer

I compiled openssl from github: . 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)

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

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

./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.

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

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.

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)

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)

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.

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

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

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

. . .

Fixed this error by running: apt install libffi7

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.

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

"...I compiled openssl from github: . 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)