openssl: libssl.so.1.1: cannot open shared object file

Why not just use an RPATH so things “just work”? Shouldn’t “just work” be the default out-of-the-box? Let those who want something special do something special.

$ lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch
Distributor ID: Fedora
Description:    Fedora release 25 (Twenty Five)
Release:        25
Codename:       TwentyFive

Build and install OpenSSL 1.1.0:

    make distclean
    ./config enable-ec_nistp_64_gcc_128
    make -j 9
    sudo make install_sw

Then:

$ bash -r
$ openssl s_client -connect pypi.python.org:443 | openssl x509 -text -noout
openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

Hmm…

$ which openssl
/usr/local/bin/openssl

And:

$ ldd /usr/local/bin/openssl
        linux-vdso.so.1 (0x00007ffe99b3e000)
        libssl.so.1.1 => not found
        libcrypto.so.1.1 => not found
        libdl.so.2 => /lib64/libdl.so.2 (0x00007ff27aec4000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff27aca4000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ff27a8dc000)
        /lib64/ld-linux-x86-64.so.2 (0x000055642bb36000)

And:

$ ls /usr/local/lib64
engines-1.1  libcrypto.so      libssl.a   libssl.so.1.1
libcrypto.a  libcrypto.so.1.1  libssl.so  pkgconfig

And:

$ ldconfig -v 2>/dev/null | grep -v ^$'\t'
/usr/lib64/bind99:
/lib:
/lib64:
/lib/sse2: (hwcap: 0x0000000004000000)
/lib64/tls: (hwcap: 0x8000000000000000)
/lib64/sse2: (hwcap: 0x0000000004000000)

Linux paths are so f**k’d up. Its sad things are still in this state in 2017.

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 19 (5 by maintainers)

Most upvoted comments

I had the same issue after installing master branch at /usr/local/openssl.

Reading through this page I managed to identify the problem and had to add the path /usr/local/openssl/lib to /etc/ld.so.conf and run ldconfig

+97

RenatoXSR on Oct 18, 2017

Some advice

Do not post to a closed issue
Do not “hijack” a closed issue with a separate problem
OpenSSH issues should be discussed on openssh groups

Hope this helps.

+53

richsalz on Jan 29, 2018

thanks to RenatoXSR

for CentOS Linux release 7.2.1511, OpenSSL 1.1.0g

please add the path /usr/local/lib64 to /etc/ld.so.conf and run ldconfig

+40

jk2K on Dec 14, 2017

What actually worked for me on CentOS 7 was: sudo yum install openssl11-libs.

+20

syslogic on Oct 15, 2020

It is still broke even with RPATHs. This is not rocket science…

bulldozer:openssl$ ./config --Wl,-rpath=/usr/local/lib
Operating system: x86_64-whatever-linux2
Configuring OpenSSL version 1.1.1-dev (0x10101000L)
for linux-x86_64
    no-aria         [default]  OPENSSL_NO_ARIA (skip dir)
    no-asan         [default]  OPENSSL_NO_ASAN
    no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
    no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
    no-devcryptoeng [default]  OPENSSL_NO_DEVCRYPTOENG
    no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128
    no-egd          [default]  OPENSSL_NO_EGD
    no-external-tests [default]  OPENSSL_NO_EXTERNAL_TESTS
    no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
    no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
    no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
    no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
    no-msan         [default]  OPENSSL_NO_MSAN
    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
    no-sctp         [default]  OPENSSL_NO_SCTP
    no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
    no-ssl3         [default]  OPENSSL_NO_SSL3
    no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
    no-tls13downgrade [default]  OPENSSL_NO_TLS13DOWNGRADE
    no-tls1_3       [default]  OPENSSL_NO_TLS1_3
    no-ubsan        [default]  OPENSSL_NO_UBSAN
    no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
    no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
    no-zlib         [default]
    no-zlib-dynamic [default]

PERL          =/usr/bin/perl
PERLVERSION   =5.24.2 for x86_64-linux-thread-multi
HASHBANGPERL  =/usr/bin/env perl
CC            =gcc
CFLAG         =-Wall -O3 -pthread -m64 -DL_ENDIAN  --Wl,-rpath,/usr/local/lib -Wa,--noexecstack
CXX           =g++
CXXFLAG       =-Wall -O3 -pthread -m64 -DL_ENDIAN  --Wl,-rpath,/usr/local/lib -Wa,--noexecstack
DEFINES       =DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM PADLOCK_ASM POLY1305_ASM
EX_LIBS       =-ldl

And then:

$ grep lib64 Makefile
LIBDIR=lib64
ENGINESDIR=/usr/local/lib64/engines-1.1

I mean, seriously… How can the project have this many problems with a simple concept?

If the project cannot keep its run paths straight and its keeps losing its shared objects, then it may as well static link. With static linking there is hope that things will “just work”.

noloader on Jul 22, 2017

Yeah, similar for me on Arch, this worked: sudo pacman -S openssl-1.1

gitaarik on Nov 28, 2022

Thanks @RenatoXSR. On Ubuntu 16 (Xenial) the missing shared object file (libssl.so.1.1) was found at /usr/local/lib, and adding it to /etc/ld.so.conf and running sudo ldconfig fixed the issue; I re-ran openssl and the problem was corrected.

LouisRitchie on Jun 20, 2019

Thank you @RenatoXSR That fixed it for me. (Ubuntu 16.04.3 LTS - OpenSSL_1_1_0-stable)

RossosHEX on Dec 1, 2017

Thanks a bunch @RenatoXSR This works on Raspbian GNU/Linux 8 (jessie)

pdxtigre on Jul 8, 2018

@RenatoXSR works on CentOS7 4.16.1-1.el7

cnrting on Apr 29, 2018