Openssl libssl.so.1.1 Not Found: 4 Easy Fixes That Work

You run a program and it stops with error while loading shared libraries: libssl.so.1.1: cannot open shared object file. This is the classic openssl libssl.so.1.1 not found problem. It happens on current Debian, Ubuntu and RHEL-family systems because they ship OpenSSL 3, while the program was built against OpenSSL 1.1. The old version of this post fixed it with two ln -s commands and no explanation of why that worked. This rewrite reproduces the error in a container and tests every fix, including the one that looks right but fails.

Lab setup: the 1.1 binary and its two libraries came from an ubuntu:20.04 container (OpenSSL 1.1.1f), and the target was a clean debian:13 container (OpenSSL 3). I copied the binary there as openssl11, the same situation as a third-party program built for 1.1. Debian 11 would have been the obvious source, but I did not use it.

Contents

• Why the openssl libssl.so.1.1 not found error appears
• Fix 1 for openssl libssl.so.1.1 not found: do not symlink OpenSSL 3
• Fix 2: put the real 1.1 libraries in /usr/local/lib and run ldconfig
• Fix 3: LD_LIBRARY_PATH or rpath for a single program
• Fix 4 on RHEL, Rocky and AlmaLinux: install the compat package
• Which fix to choose
• Questions about the openssl libssl.so.1.1 not found error

Why the openssl libssl.so.1.1 not found error appears

A binary records the exact library name it needs, here libssl.so.1.1 and libcrypto.so.1.1. The dynamic loader looks that name up in its cache; if no file has that name, the program does not start. Debian 13 only has the OpenSSL 3 files:

$ openssl11 version
openssl11: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

$ ldd /usr/local/bin/openssl11 | grep -E "libssl|libcrypto"
	libssl.so.1.1 => not found
	libcrypto.so.1.1 => not found

$ ls /usr/lib/x86_64-linux-gnu | grep -E "^lib(ssl|crypto)"
libcrypto.so.3
libssl.so.3

ldd is the first command to run on any "cannot open shared object file" error. It lists every library the binary wants and marks the missing ones. On Debian 13, apt-cache policy libssl1.1 printed nothing, so there is no package to install. The same applies to Ubuntu: in the lab, Ubuntu 22.04 offers only libssl3, and Ubuntu 24.04 only libssl3t64.

Fix 1 for openssl libssl.so.1.1 not found: do not symlink OpenSSL 3

The old advice, and many forum answers, say to link the missing name to a library you already have. With OpenSSL 3 that looks like it works, because ldd becomes happy:

$ ln -s /usr/lib/x86_64-linux-gnu/libssl.so.3 /usr/lib/x86_64-linux-gnu/libssl.so.1.1
$ ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.3 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
$ ldd /usr/local/bin/openssl11 | grep -E "libssl|libcrypto"
	libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f474ec9f000)
	libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f474e665000)
$ openssl11 version
openssl11: /lib/x86_64-linux-gnu/libssl.so.1.1: version `OPENSSL_1_1_1' not found (required by openssl11)
openssl11: /lib/x86_64-linux-gnu/libssl.so.1.1: version `OPENSSL_1_1_0' not found (required by openssl11)
openssl11: /lib/x86_64-linux-gnu/libcrypto.so.1.1: version `OPENSSL_1_1_1' not found (required by openssl11)
openssl11: /lib/x86_64-linux-gnu/libcrypto.so.1.1: version `OPENSSL_1_1_0' not found (required by openssl11)

The file name matched, but the library inside is a different major version. Its symbols carry the version tag OPENSSL_3.0.0, not OPENSSL_1_1_1, so the program still refuses to run. Worse, the fake .so.1.1 files sit in the system library directory, where they can confuse the next person who looks. Remove them if you made them. The old post linked to /usr/local/lib64/libssl.so.1.1, a real 1.1 library built from source, which is why it worked on that machine and not by renaming.

Fix 2: put the real 1.1 libraries in /usr/local/lib and run ldconfig

You need the actual OpenSSL 1.1 files. Take them from a package of an older release, from the vendor of the program, or build OpenSSL 1.1.1 from source into a private directory. In the lab I copied the two files into /usr/local/lib. Without any further step the loader still does not find them, because it uses a cache and /usr/local/lib is not listed on this system:

$ mkdir -p /usr/local/lib/openssl11
$ cp libssl.so.1.1 libcrypto.so.1.1 /usr/local/lib/openssl11/
$ ldd /usr/local/bin/openssl11 | grep -E "libssl|libcrypto"
	libssl.so.1.1 => not found
	libcrypto.so.1.1 => not found

That directory was not in the cache either, so this attempt failed. Register the directory with a file in /etc/ld.so.conf.d and rebuild the cache:

$ echo /usr/local/lib > /etc/ld.so.conf.d/openssl11.conf
$ ldconfig
$ ldconfig -p | grep -E "libssl|libcrypto"
	libssl.so.3 (libc6,x86-64) => /lib/x86_64-linux-gnu/libssl.so.3
	libssl.so.1.1 (libc6,x86-64) => /usr/local/lib/libssl.so.1.1
	libcrypto.so.3 (libc6,x86-64) => /lib/x86_64-linux-gnu/libcrypto.so.3
	libcrypto.so.1.1 (libc6,x86-64) => /usr/local/lib/libcrypto.so.1.1
$ openssl11 version
OpenSSL 1.1.1f  31 Mar 2020

Both major versions now live side by side. OpenSSL 3 keeps serving every program that needs it, and the old binary finds its own 1.1 libraries by name. I also made a real TLS connection with the old binary to confirm the pair works:

$ openssl11 s_client -connect deb.debian.org:443 </dev/null | grep -E "Protocol|Cipher"
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_128_GCM_SHA256

Use this fix when the library is needed by several programs. The cache entry is global and permanent until you remove the file and run ldconfig again. The loader's lookup order is described in the ld.so(8) manual page.

Fix 3: LD_LIBRARY_PATH or rpath for a single program

If only one program needs the old libraries, avoid a system-wide change. The environment variable applies to one command:

$ LD_LIBRARY_PATH=/usr/local/lib openssl11 version
OpenSSL 1.1.1f  31 Mar 2020
$ openssl11 version
openssl11: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

The second command shows the limit: the variable does not persist. For a service, set it in the unit file with Environment=LD_LIBRARY_PATH=.... Do not export it in a shell profile, because every program you start afterwards would prefer those libraries.

The cleaner way for one binary is to store the path inside the file with patchelf (the patchelf package on Debian):

$ patchelf --set-rpath /usr/local/lib /usr/local/bin/openssl11
$ ldd /usr/local/bin/openssl11 | grep -E "libssl|libcrypto"
	libssl.so.1.1 => /usr/local/lib/libssl.so.1.1 (0x00007f548344e000)
	libcrypto.so.1.1 => /usr/local/lib/libcrypto.so.1.1 (0x00007f5483177000)
$ patchelf --print-rpath /usr/local/bin/openssl11
/usr/local/lib

This changes the binary itself, so keep a copy of the original and do not do it to a file managed by a package manager, which will overwrite your edit on the next upgrade.

Fix 4 on RHEL, Rocky and AlmaLinux: install the compat package

Red Hat built a package for exactly this case. On Rocky Linux 9, dnf tells you which package provides the missing name:

$ dnf provides "libssl.so.1.1()(64bit)"
compat-openssl11-1:1.1.1k-5.el9_8.2.x86_64 : Utilities from the general purpose cryptography library with TLS implementation
Repo        : appstream
Matched from:
Provide    : libssl.so.1.1()(64bit)
$ dnf install compat-openssl11
$ ls -l /usr/lib64 | grep -E "libssl|libcrypto"
lrwxrwxrwx. 1 root root      19 Oct 12 09:46 libcrypto.so.1.1 -> libcrypto.so.1.1.1k
lrwxrwxrwx. 1 root root      18 Oct 28  2023 libcrypto.so.3 -> libcrypto.so.3.0.7
lrwxrwxrwx. 1 root root      16 Oct 12 09:46 libssl.so.1.1 -> libssl.so.1.1.1k
lrwxrwxrwx. 1 root root      15 Oct 28  2023 libssl.so.3 -> libssl.so.3.0.7

The package installs the real 1.1.1 libraries next to the 3.0 ones and registers them, so no manual linking is needed. This is the best answer on that family because it is signed, updated, and removable. dnf provides works for any missing library name, so use it before searching the web.

The error, the failed symlink and the working fix, from the real lab output.

Which fix to choose

• RHEL, Rocky, AlmaLinux: dnf install compat-openssl11.
• Debian and Ubuntu with no package: copy the real 1.1 libraries to a private directory and use ldconfig for shared use or LD_LIBRARY_PATH/rpath for one program.
• Never rename the OpenSSL 3 files. The check shown above prints version OPENSSL_1_1_1 not found.
• Best long-term fix: get a build of the program made for OpenSSL 3, because OpenSSL 1.1.1 no longer gets security fixes from the OpenSSL project.

On the last point, see the OpenSSL release strategy. If you must keep a 1.1 library around, treat it as legacy and keep it away from anything exposed to the internet.

Questions about the openssl libssl.so.1.1 not found error

Is the error caused by a broken OpenSSL install? No. OpenSSL 3 is installed and fine. The program was built for an older major version whose files are no longer in the distribution.

The error mentions libcrypto.so.1.1 instead. Same cause. The two libraries always travel together, so you need both files.

Can I use the 1.1 libraries from another distribution? In the lab, the Ubuntu 20.04 libraries ran correctly on Debian 13, because both depend on the same C library interface. Check with ldd on each library for missing dependencies first. For internet-facing use, prefer the compat package or a vendor build.

For other loader problems, a similar read of the missing name works; compare it with how systemd handles unit environment variables when the program runs as a service.