How to resolve openssl error when loading shared libraries libssl.so.1.1

Jan 15, 2025

Cowrie

Dev @ Bswen

1. The purpose of this post

After install openssl, we run the below command:

openssl version

to verity the installation, but sometimes we would get this error:

[root@node1 openssl-1.1.0f]# openssl version
openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

2. Environments

The linux system is:

[root@node1 openssl-1.0.0f]# uname -a
Linux node1 3.10.0-862.14.4.el7.x86_64 #1 SMP Wed Sep 26 15:12:11 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

3. Debug

We try to find the file named libssl.so.1.1 as follows:

[root@localhost openssl-1.1.0f]# ll /usr/lib64/libssl*
-rwxr-xr-x. 1 root root 315096 8m   7 2017 /usr/lib64/libssl3.so
lrwxrwxrwx. 1 root root     16 7m   9 2009 /usr/lib64/libssl.so.10 -> libssl.so.1.0.2k
-rwxr-xr-x. 1 root root 470336 8m   4 2017 /usr/lib64/libssl.so.1.0.2k
[root@localhost openssl-1.1.0f]# ll /usr/local/lib64
Total 8984
drwxr-xr-x. 2 root root      39 11m  8 11:30 engines-1.1
-rw-r--r--. 1 root root 4967326 11m  8 11:30 libcrypto.a
lrwxrwxrwx. 1 root root      16 11m  8 11:30 libcrypto.so -> libcrypto.so.1.1
-rwxr-xr-x. 1 root root 2934272 11m  8 11:30 libcrypto.so.1.1
-rw-r--r--. 1 root root  766182 11m  8 11:30 libssl.a
lrwxrwxrwx. 1 root root      13 11m  8 11:30 libssl.so -> libssl.so.1.1
-rwxr-xr-x. 1 root root  521384 11m  8 11:30 libssl.so.1.1
drwxr-xr-x. 2 root root      61 11m  8 11:22 pkgconfig

We can find that the libcrypto.so.1.1 is located in the /usr/local/lib64, But openssl try to find the .so libraries in the LD_LIBRARY_PATH:

[root@localhost ~]# echo $LD_LIBRARY_PATH
/usr/lib64:/usr/local/lib64

So the solution is try to tell openssl where the library is.

4. Resolve it

There are two methods to resolve this problem:

4.1 Method 1: Change the LD_LIBRARY_PATH

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

LD_LIBRARY_PATH

LD_LIBRARY_PATH is an environment variable in Linux and other Unix-like operating systems. It specifies a list of directories where the dynamic linker (ld.so or ld-linux.so) should look for shared libraries before searching the standard library paths (like /lib and /usr/lib).

Purpose When you run a program that depends on shared libraries, the dynamic linker uses LD_LIBRARY_PATH to locate the necessary libraries if they aren’t in the default locations. This is especially useful for:

• Running applications that use custom or non-standard library versions.
• Testing new libraries without overwriting system-wide libraries.
• Developing and debugging software.

4.2 Method 2: Create a link to the file

[root@localhost openssl-1.1.0f]# ln -s /usr/local/lib64/libssl.so.1.1 /usr/lib64/libssl.so.1.1
[root@localhost openssl-1.1.0f]# ln -s /usr/local/lib64/libcrypto.so.1.1 /usr/lib64/libcrypto.so.1.1

5. More about the LD_LIBRARY_PATH

As the linux documents shown:

More about the LD_LIBRARY_PATH

You can temporarily substitute a different library for this particular execution. In Linux, the environment variable LD_LIBRARY_PATH is a colon-separated set of directories where libraries should be searched for first, before the standard set of directories; this is useful when debugging a new library or using a nonstandard library for special purposes. The environment variable LD_PRELOAD lists shared libraries with functions that override the standard set, just as /etc/ld.so.preload does. These are implemented by the loader /lib/ld-linux.so. I should note that, while LD_LIBRARY_PATH works on many Unix-like systems, it doesn’t work on all; for example, this functionality is available on HP-UX but as the environment variable SHLIB_PATH, and on AIX this functionality is through the variable LIBPATH (with the same syntax, a colon-separated list).

LD_LIBRARY_PATH is handy for development and testing, but shouldn’t be modified by an installation process for normal use by normal users; see “Why LD_LIBRARY_PATH is Bad” at http://www.visi.com/~barr/ldpath.html for an explanation of why. But it’s still useful for development or testing, and for working around problems that can’t be worked around otherwise. If you don’t want to set the LD_LIBRARY_PATH environment variable, on Linux you can even invoke the program loader directly and pass it arguments. For example, the following will use the given PATH instead of the content of the environment variable LD_LIBRARY_PATH, and run the given executable:

  /lib/ld-linux.so.2 --library-path PATH EXECUTABLE

Just executing ld-linux.so without arguments will give you more help on using this, but again, don’t use this for normal use - these are all intended for debugging.

Final Words + More Resources

My intention with this article was to help others who might be considering solving such a problem. So I hope that’s been the case here. If you still have any questions, don’t hesitate to ask me by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

• 👨‍💻 Linux shared libraries documents
• 👨‍💻 LIBRARY_PATH vs LD_LIBRARY_PATH
• 👨‍💻 the full linux shared libary documents

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Tags:

• sys

How to resolve 'plugin org.springframework.boot was not found in any of the following sources exception' when building spring boot applications with gradle

how to solve `Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent` problem when running android app on android 12 ?