22

When I run "openssl" I am getting an error as below :

openssl: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory"

This happened after I attempted to update OpenSSL according to this article

Is there anyway to fix this?

OS : CentOS 6.8 Web server : nginx/1.10.2

Update #1 :

[root@host ~]# yum info openssl
Installed Packages
Name        : openssl
Arch        : x86_64
Version     : 1.0.1e
Release     : 48.el6_8.3
Size        : 4.0 M
Repo        : installed
From repo   : system-updates
Summary     : A general purpose cryptography library with TLS implementation
URL         : ***
License     : OpenSSL
Description : The OpenSSL toolkit provides support for secure communications
            : between machines. OpenSSL includes a certificate management tool and
            : shared libraries which provide various cryptographic algorithms and
            : protocols.

Available Packages
Name        : openssl
Arch        : i686
Version     : 1.0.1e
Release     : 48.el6_8.3
Size        : 1.5 M
Repo        : system-updates
Summary     : A general purpose cryptography library with TLS implementation
URL         : ***
License     : OpenSSL
Description : The OpenSSL toolkit provides support for secure communications
            : between machines. OpenSSL includes a certificate management tool and
            : shared libraries which provide various cryptographic algorithms and
            : protocols.
mayasl
  • 329
  • 1
  • 2
  • 4
  • 3
    Sorry, you've run into yet another bad Internet tutorial. You might have to reinstall the system. Before going further, I suggest you ask about the original problem that you were trying to solve by doing this. There is probably a better way to accomplish the original goal. – Michael Hampton Dec 02 '16 at 20:01
  • I wanted to install Server Monitor application provided by Monitis. It needed some shared library dependencies which was not installed in my server. So, all this happened when was up to install those. :( – mayasl Dec 02 '16 at 20:19
  • @MichaelHampton Please tell me something except reinstalling the system. Because a live site is running on that server! – mayasl Dec 02 '16 at 20:29
  • Way late here, but ***DO NOT DO WHAT THAT ARTICLE SAYS!!!!!*** It will break your system. `mv /usr/bin/openssl /root/` and then `ln -s /usr/local/ssl/bin/openssl /usr/bin/openssl`?!?!?! Now you've completely hosed your system - what happens if an update tries to update `/usr/bin/openssl`? – Andrew Henle Feb 16 '21 at 11:58
  • OpenSSL 1.1.0 and later is not binary-compatible with the OpenSSL 1.0.2 branch that is the basis of Centos 7's OS-installed OpenSSL. See https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes ***Doing this to your Centos 7 system will break every OS component that uses OpenSSL.*** – Andrew Henle Feb 16 '21 at 12:29

14 Answers14

26

I was having the same issue after install the last version of openssl 1.1.0c, I resolved the issue copying the library files libcrypto.so.1.1, libcrypto.a and libssl.so from /usr/local/lib64 to the share library at /usr/lib64.
After copy the libraries you need to create the symbolic link.

ln -s libcrypto.so.1.1 libcrypto.so
ln -s libssl.so.1.1 libssl.so

After creating the symbolic link rebuilding the ldconfig cache was required as well:

sudo ldconfig
Castaglia
  • 3,349
  • 3
  • 21
  • 42
Benedict
  • 277
  • 2
  • 2
  • 1
    `.so` without versions are installed by dev packages, just install `openssl-dev`. – Maxim Egorushkin Jun 24 '20 at 11:55
  • 5
    -1. ***NEVER*** overwrite OS-supplied executables like `/usr/bin/openssl` or libraries `/usr/lib64/libcrypto.so` with something you compiled yourself unless you want to break your system. Are you going to do security updates to your installation? How are you going to test if `yum update` breaks things? You didn't even **bother** testing your now-custom operating system, did you? What are you going to do ***when*** an update overwrites your "improved" executables and/or libraries? – Andrew Henle Feb 16 '21 at 12:01
  • +1. @AndrewHenle All this does not matter, when doing it inside a Docker container. – Akito Aug 20 '23 at 13:19
  • @Akito Oh? So you fully regression tested **everything** inside that Docker container that uses SSL? **And** you plan on keeping a watch on OpenSSL vulnerabilities as they're discovered and rebuilding **and retesting** everything whenever a critical OpenSSL vulnerability is discovered? Yeah. Didn't think so. I also wonder what kind of response you'd give if one of the users of your Docker containers were to ask you to verify that all the code you put into that container was verified to be from secure sources. – Andrew Henle Aug 20 '23 at 15:26
  • @AndrewHenle For discovering what Docker is & how it works, you can read up on the following sources. https://www.docker.com/ https://docs.docker.com/get-started/overview/ https://kinsta.com/knowledgebase/what-is-docker/ There are also plenty of books & other resources regarding that technology. – Akito Aug 24 '23 at 16:15
  • @Akito So no, even though you advocate rolling your own OpenSSL implementation, you don't do any due diligence to keep it up-to-date? And you try to obfuscate that with irrelevant links to Docker marketing material? Docker - Solaris zones done poorly decades after the original. – Andrew Henle Aug 24 '23 at 17:32
16

With your original version of OpenSSL it knew how to find the shared libs because /usr/lib64 is included in the linker's search path. When you downloaded and compiled a "local" copy of OpenSSL, the shared libs were placed in /usr/local/lib64 by default. So you probably just need to add this directory to the search path of the linker, like this (as root):

echo "/usr/local/lib64" > /etc/ld.so.conf.d/openssl.conf

then execute:

ldconfig

I believe this will resolve your issue.

chicks
  • 3,793
  • 10
  • 27
  • 36
doug.fsu
  • 161
  • 1
  • 2
  • In at least modern Ubuntu distributions (I'm writing this on 16.04 LTS) and probably others, `sudo echo "/usr/local/lib64" > /etc/ld.so.conf.d/openssl.conf` will result in a "permission denied" error because the second half of the command (the file write) isn't executed as root. If this happens, try `sudo sh -c "echo '/usr/local/lib64' >> /etc/ld.so.conf.d/openssl.conf"` instead. – Matthew Cole Feb 21 '18 at 18:15
4

You can reinstall it using

yum install -y openssl-devel

mzhaase
  • 3,798
  • 2
  • 20
  • 32
  • I tried it as well, but didn't help! – mayasl Dec 02 '16 at 20:19
  • @mayasl Maybe you need to reinstall other packages as well. I would expect a package called `openssl-devel` to depend on a package called `openssl`. Bare in mind that it has been a long time since I touched `yum`, so I cannot verify the syntax of the command for you. – kasperd Dec 02 '16 at 21:37
  • I have updated my question with the output of "yum info openssl". Please take a look, if it is useful. I removed and reinstalled openssl and openssl-devel before starting this thread. Didn't work! Commands I used : `code` yum remove openssl yum remove openssl-devel yum clean all – mayasl Dec 02 '16 at 22:02
  • Reinstalling `openssl`, (and not `openssl-devel`) should be a good start. – Michael Hampton Dec 02 '16 at 22:03
  • I already tried that @MichaelHampton Is this some sort of linking issue??? – mayasl Dec 02 '16 at 22:08
  • Does the file exist? – mzhaase Dec 03 '16 at 12:05
  • Can you look for broken symlinks in /lib* and /usr/lib*? It sounds like one of your LD environment variables finds a match for the shared library OpenSSL is attempting to open before reaching the one provided by your package manager. – Ginnungagap Dec 04 '16 at 22:42
4

I got this error using Termux on ChromeOS, which caused the npm and node command line programs to crash.

Running pkg upgrade fixed the problem!

Carl Walsh
  • 221
  • 2
  • 4
2

The libcrypto.so belongs to openssl-libs package. If you manually force removed (with --nodeps) this package or corrupted it by upgrading it, you will lose access to yum, wget, curl, ssh, etc. If the system has Internet access, download the openssl-libs using the command /usr/bin/GET. The syntax would look like the below if you're trying to restore version openssl-libs-1.0.2k-8.el7.x86_64:

/usr/bin/GET http://downloadURL/openssl-libs-1.0.2k-8.el7.x86_64.rpm > openssl-libs-1.0.2k-8.el7.x86_64.rpm

This will create openssl-libs-1.0.2k-8.el7.x86_64.rpm package for you, you can use this to either re-install or extract the missing .so file.

chicks
  • 3,793
  • 10
  • 27
  • 36
Karthik
  • 114
  • 4
1

Tried all the above answers but to no avail. I made a post on SO to install openssl11-libs if it doesn't exist on your server.

Check my SO post out

Young Emil
  • 111
  • 2
1

Solution for CentOS 7

yum install epel-release
yum install openssl11-libs
Eugene Lebedev
  • 111
  • 1
  • 4
1

What @benedict said worked for me. However you may find that some of the symlinks are pointing to older versions. Running ls -l libcrypto* from the /usr/libs will show you the links. As in the below example:

lrwxrwxrwx 1 root root      16 May 21 15:28 libcrypto.so -> libcrypto.so.1.0

Then you would want to remove the existing link first by typing sudo rm libcrypto.so and then copying libcrypto.so.1.1 as @benedict mentioned. Finally you can create the new link. sudo ln -s libcrypto.so.1.1 libcrypto.so

Hope this helps.

Ihsan Izwer
  • 11
  • 2
0

I know this is an old post. I recently got the exactly same error and fixed by applying libssl.1.1 package, which can be downloaded from

https://ubuntu.pkgs.org/18.04/ubuntu-main-amd64/libssl1.1_1.1.0g-2ubuntu4_amd64.deb.html

j3ffyang
  • 170
  • 1
  • 4
0

One of the problems is that once the openssl is deleted, you will not be able to do su or sudo.. They fail. This is the solution for Fedora 35.

I had another system with the same files, so I did an FTP from that system to my ailing system storing the files in /home/turgut/ssl since root access was impossible. If you have a backup or something, simply copy everything in /lib64/* to that folder.

Then downloaded the openssl-libs-1.1.1n-1.fc35.x86_64.rpm

Also had a live USB of fedora. Booted the USB, selected "rescue/recover an installed system" or whatever it says. Select 1 for Continue finding installed system. Once it boots up, your current operating system will be mounted under /mnt/sysimage.

(The BIG plus of the live USB is that it ALSO checks the CURRENT directory for the missing library files. so if you can extract or copy from somewhere the missing SSL files, you can then run rpm -ivh..)

Now do a chroot /mnt/sysimage and change to the path where you copied the SSL files, in my case cd /home/turgut/ssl

Now you can actually run the rpm -ivh from there.. In my case: rpm -ivh ../Desktop/openssl-libs-1.1.1n-1.fc35.x86_64.rpm

It will find the ftp'ed SSL files in its current directory, hence it will be able to run rpm without problems.. Now just reboot and hopefully it will all work out.

For safety sake, you may wish to do a:

dnf reinstall "rpm -qa|grep ssl"

PS: The above line contains backticks -- not double quotes.

(it runs the quoted part, gets a list of packages with the keyword "ssl" in it and then reinstalls those).

so that any missing OTHER ssl files are likewise reinstalled.

Turgut Kalfaoglu
  • 11
  • 2
0

This is best solution I have found around ...other solutions provided all over the internet, will not survive system reboot ;)

OS: Ubuntu 16.04 

sudo vim /etc/ld.so.conf.d/libc.conf

Comment lib directory settings and add good path

# libc default configuration

#/usr/local/lib

/usr/lib

When you are done editing, run this command:

sudo ldconfig

Then you will have good setting when you run:

ldd /usr/bin/openssl

Before this fix:

 /usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version information available (required by /usr/bin/openssl)
 /usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/openssl)
linux-vdso.so.1 =>  (0x00007ffe6d1e3000)
libssl.so.1.0.0 => /usr/local/lib/libssl.so.1.0.0 (0x00007f8999827000)
libcrypto.so.1.0.0 => /usr/local/lib/libcrypto.so.1.0.0 (0x00007f89993ed000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8999023000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8998e1f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8999a97000)

After fix I provided:

linux-vdso.so.1 =>  (0x00007ffec39bc000)
libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f7faad22000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f7faa8dd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7faa513000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7faa30f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7faaf8b000)
ZEROF
  • 1
  • 1
  • For people with CentOS path, I think good file is /etc/ld.so.conf ;), just to be clear. – ZEROF Jun 07 '19 at 20:16
0

On CentOS 7 libssl.so.1.1 resides in /usr/local/ssl/lib.

So I just had to add this path to default locations, where dynamic loader looks for libraries. I created a separate file for my openssl binary, named openssl-1.1.1c.conf, in /etc/ld.so.conf.d folder:

echo "/usr/local/ssl/lib" > /etc/ld.so.conf.d/openssl-1.1.1c.conf

Now it works.

Boris Burkov
  • 113
  • 4
-1

I am gone through the exactly same issue... I have solved it by running the following commands.

ln -s /usr/local/lib/libcrypto.so.1.1 /usr/lib/libcrypto.so.1.1

This will create a softlink and you are good to go.

Faheem
  • 1
  • *This will create a softlink and you are good to go.* That will just break things. Are you planning on making sure there are not exploits in your now-custom OpenSSL implementation? And taking the time to keep it up-to-date? – Andrew Henle Feb 16 '21 at 12:05
-1

After building and installing open ssl openssl-1.1.0f, I fixed same error for lib libssl.so.1.1 creating a soft link :

ln -s /usr/local/lib/libssl.so.1.1 /usr/lib/libssl.so.1.1

Rafael
  • 101
  • 1