Error while loading shared libraries: /usr/local/lib64/libssl.so.1.1

Question

I’m trying to compile openssl-1.1.0e on Centos 7 (7.3.1611) but after i successfully compiled everything without any warning, i get an error when i’m trying any openssl command

[mdm@dev openssl-1.1.0e]$ openssl version
openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

Is it a bug or my mistake?

Here below some info about my system/configuration

Configure:

[mdm@dev openssl-1.1.0e]$ ./Configure linux-x86_64 --prefix=/usr/local --openssldir=/usr/local

Make/Make test:

...
All tests successful.
Files=91, Tests=486, 44 wallclock secs ( 0.47 usr  0.08 sys + 27.72 cusr 13.41 csys = 41.68 CPU)
Result: PASS
...

Make install:

...
install libcrypto.a -> /usr/local/lib64/libcrypto.a
install libssl.a -> /usr/local/lib64/libssl.a
install libcrypto.so.1.1 -> /usr/local/lib64/libcrypto.so.1.1
link /usr/local/lib64/libcrypto.so -> /usr/local/lib64/libcrypto.so.1.1
install libssl.so.1.1 -> /usr/local/lib64/libssl.so.1.1
link /usr/local/lib64/libssl.so -> /usr/local/lib64/libssl.so.1.1
...

But if i check with ldd two libraries are not found despite Make install did its job...

[mdm@dev openssl-1.1.0e]$ ldd /usr/local/bin/openssl
linux-vdso.so.1 =>  (0x00007fffcfe75000)
/lib/$LIB/liblsp.so => /lib/lib64/liblsp.so (0x00007fa5cd77a000)
libssl.so.1.1 => not found
libcrypto.so.1.1 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007fa5cd55d000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa5cd341000)
libc.so.6 => /lib64/libc.so.6 (0x00007fa5ccf7f000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa5cd981000)

I have already installed by distro a version of openssl:

[mdm@dev]$ openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

[mdm@dev]$ which openssl
/usr/bin/openssl

yum info openssl:

...
Installed Packages
Name        : openssl
Arch        : x86_64
Epoch       : 1
Version     : 1.0.1e
Release     : 60.el7_3.1
Size        : 1.5 M
Repo        : installed
From repo   : updates
...

Appreciate any help or suggestion!

Answer 1

Information from NOTES-UNIX.md in Github:

Every Unix system has its own set of default locations for shared libraries, such as /lib, /usr/lib or possibly /usr/local/lib. If libraries are installed in non-default locations, dynamically linked binaries will not find them and therefore fail to run, unless they get a bit of help from a defined runtime shared library search path.

For OpenSSL's application (the openssl command), our configuration scripts do NOT generally set the runtime shared library search path for you. It's therefore advisable to set it explicitly when configuring, unless the libraries are to be installed in directories that you know to be in the default list.

Please do not use verbatim directories in your runtime shared library search path! Some OpenSSL config targets add an extra directory level for multilib installations. To help with that, the produced Makefile includes the variable LIBRPATH, which is a convenience variable to be used with the runtime shared library search path options

1. Set the search path

$ ./Configure --prefix=/usr/local/ssl --openssldir=/usr/local/ssl '-Wl,-rpath,$(LIBRPATH)'

2. Build the libraries and executables

$ make

3. Test the output

$ make test

4. Install openssl into your Linux

$ sudo make install

5. Check whether the new version is activated

$ openssl version

6. If the previous step still shows the old version, then find where is old version is stored

$ which openssl

7. If the previous step shows the old location to be'/usr/bin/openssl', then use the following:

Executables under /usr/bin are mostly symlinks to the original file. Could you please first check whether /usr/bin/openssl is a symlink with

$ ls -l /usr/bin/openssl

If it is a symlink (and probably it is), you can delete this symlink (noting the path it directs to for future reference. You can create a new link as such:

$ sudo ln -s /usr/local/ssl/bin/openssl /usr/bin/openssl

If the /usr/bin/openssl is itself an executable, you can do:

$ sudo mv /usr/bin/openssl /usr/bin/openssl-old

and repeat the symlink creation command above. This way, any references that point to the absolute path would not be broken.

Answer 2

Uninstall the current version of the openssl and then download older version of openssl[http://archive.ubuntu.com/ubuntu/pool/main/o/openssl/] and install it using dpkg -i

Answer 3

This Worked for me...

1. Open the terminal on your Ubuntu system.

2. Execute the following command to add the focal-security repository:

   echo "deb http://security.ubuntu.com/ubuntu focal-security main" | sudo tee /etc/apt/sources.list.d/focal-security.list

This command adds a new repository entry to the /etc/apt/sources.list.d/focal-security.list file, which contains the necessary security updates for the Ubuntu focal release.

3. Next, run the following command to update the package lists:

   sudo apt update

This command retrieves the latest package information from all configured repositories, including the newly added focal-security repository.

4. Finally, install the libssl1.1 package by executing the following command:
   sudo apt install libssl1.1

This command installs the libssl1.1 package, which provides the OpenSSL cryptographic library version 1.1. This command installs the libssl1.1 package, which provides the OpenSSL cryptographic library version 1.1.

Answer 4

this might do the trick

sudo apt-get install libssl1.1

Answer 5

I suggest you to use a semi-official OpenSSL 1.1 package openssl11 from the EPEL repo instead of compiling it from scratch with:

# if you don't have EPEL repo yet...
yum install -y epel-release

# ...and then:
yum install -y openssl11

Answer 6

I know this is late but in my case I did not have the libssl.so.1.1 on my server. There was a recommendation here to install openssl11-libs but not openssl11 as installing it could create problems.

Confirm you dont have libssl.so.1.1 on your server probably by trying locate libssl.so.1.1.

Simply do sudo yum install -y openssl11-libs if you don't have the libssl.so.1.1 library on your server.

It worked for me.

Answer 7

Sometime when you want climb the mountain you looking just the top without checking if something can help you on the base...

In my case I solved just exporting LD_LIBRARY_PATH before compile it again.

export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64

and after

sudo ldconfig

that should keep saved the path also after rebooting machine (and also for next times)

Answer 8

For CentOS 7+, Add the following to /etc/environment:

LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64

Answer 9

jk2K solved my issue

For OpenSSL 1.1.0g, CentOS 7.2.1511, you can try this:

sudo bash -c "echo '/usr/local/lib64' >> /etc/ld.so.conf"
sudo ldconfig

Answer 10

We ran into same problems after upgrading openssl from 1.0.2g to 1.1.0g. The required libraries were present and also the soft link was present.

sudo ldconfig 

worked for us. It rebuilt ldconfig cache.

Answer 11

thanks to levitte, RenatoXSR

for OpenSSL 1.1.0g, CentOS 7.2.1511, you can try this

sudo bash -c "echo '/usr/local/lib64' >> /etc/ld.so.conf"
sudo ldconfig

this link explains the cause of problem

The use of RPATH is inconsistent. On some systems, ld.so considers RPATH before even looking at LD_LIBRARY_PATH, which makes it hard to override, for example when testing a new OpenSSL build (!). We did so in pre-1.1.0 versions by hacking LD_PRELOAD, but there are some sanitizers that do not agree with that, which makes life hard as well, for example when testing a new OpenSSL build (!)

this link gave an solution example

Answer 12

Try this:

ldd libssl.so   ->  libcrypto.so.1.1 => not found
sudo ln -s /usr/local/lib64/libcrypto.so.1.1 /usr/lib64/libcrypto.so.1.1
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f17d46c7000)

Answer 13

In this case, you should configure OpenSSL with:

./Configure linux-x86_64 enable-ec_nistp_64_gcc_128 -Wl,-rpath=/usr/local/lib64 \ --prefix=/usr/local --openssldir=/usr/local OpenSSL does not add RPATHs by default (except on some of the BSDs). You need to manually specify it in your configure command. Once you manually specify it, things will "just work" for you without the need for LD_LIBRARY_PATH tricks.

i have followed your advice but still same error if i don't specify LD_LIBRARY_PATH it doesn't work anyway...

[mdm@dev openssl-1.1.0e]$ export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64

[mdm@dev openssl-1.1.0e]$ ldd /usr/local/bin/openssl 
    linux-vdso.so.1 =>  (0x00007ffc87aef000)
    /lib/$LIB/liblsp.so => /lib/lib64/liblsp.so (0x00007f57511fa000)
    libssl.so.1.1 => /usr/local/lib/libssl.so.1.1 (0x00007f5750f8c000)
    libcrypto.so.1.1 => /usr/local/lib/libcrypto.so.1.1 (0x00007f5750ae8000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f57508cb000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f57506ae000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f57502ed000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f5751401000)
[mdm@dev openssl-1.1.0e]$ openssl version
OpenSSL 1.1.0e  16 Feb 2017

It looks like i have to use LD_LIBRARY_PATH anyway I wonder if that is normal or is just misbehavior in my machine for some reasons that my knowledge can't figure it out...

Answer 14

Configure:

[mdm@dev openssl-1.1.0e]$ ./Configure linux-x86_64 --prefix=/usr/local --openssldir=/usr/local

In this case, you should configure OpenSSL with:

./Configure linux-x86_64 enable-ec_nistp_64_gcc_128 -Wl,-rpath=/usr/local/lib64 \
  --prefix=/usr/local --openssldir=/usr/local

OpenSSL does not add RPATHs by default (except on some of the BSDs). You need to manually specify it in your configure command. Once you manually specify it, things will "just work" for you without the need for LD_LIBRARY_PATH tricks.

The enable-ec_nistp_64_gcc_128 is applicable to x86_64. It makes Diffie-Hellman run 2x to 4x faster. The option has some restrictions, so be careful when using it (but you are safe on x86_64).

Also see Compilation and Installation on the OpenSSL wiki. There is a discussion of RPATHs, and a discussion of enable-ec_nistp_64_gcc_128.