I've tried the following, but I can't get a build date later than:

Tue, Aug 21 05:18:46 UTC 2012

I have done the following:

apt-get dist-upgrade
apt-get update
apt-get upgrade openssl


apt-get purge openssl
apt-get install openssl


apt-get purge libcrypto1.0.0
apt-get install libcrypto1.0.0

Everything seems to work fine, but the build date remains as above. And the http://filippo.io/Heartbleed/ test is still failing.

I know I'm not crazy, because I was able to update my identical server Wednesday. (Identical in EVERY way except hardware).


I compared the /etc/apt/sources.list files on both machines and they appear to be identical. How did one server update and the other won't?


Did as suggested:

apt-get purge openssl
apt-get install openssl

to no avail.

Tried same commands on libssl1.0.0, still same version as listed above.

This one's got me stumped.

Any suggestions?


As soon as I get enough street cred (15), I will +1 the viable workarounds


As suggested, I ran apt-get with --reinstall --print-uris and got back:


Then rebooted, same version as listed above. Still failing heartbleed.

  • Did you reboot? Old/vulnerable copies will remain in use/memory so long as the processes using them do. Apr 12, 2014 at 22:41
  • try rebooting. and try getting the debs off of the ubuntu packages site or something like that. Also, you can upvote on your own questions, and leave comments too, even below the points barrier.
    – Wyatt Ward
    Apr 13, 2014 at 2:37
  • What is reported for dpkg-query --list libssl1.0.0 next, what is "Filename:" from apt-cache show libssl1.0.0 next, does that match the file you get when you apt-get download libssl1.0.0? Apr 13, 2014 at 8:57
  • Also helpful, apt-get clean to clear your download cache, then apt-get install openssl libssl1.0.0 --reinstall --print-uris and check the download URIs. Download the packages manually to inspect. Apr 13, 2014 at 9:11
  • Thanks Maxx, I ran the dpkg-query and apt-get download, and the versions match. I then ran apt-get clean, downloaded the packages and inspected their content, which matched the dpkg-query versions. Does that mean the repository is broken? Apr 13, 2014 at 13:42

4 Answers 4


Forcing a package re-installation

Apt thinks that the packages are installed and upgraded. Manual verification and testing of libssl suggests otherwise, so the package database is inconsistent with the installed files (maybe files were previously upgraded previously without package manager involvement). For whatever reason this happened, the package is not being correctly upgraded or reinstalled. This assumes that it has been established that the system is reporting fixed versions, but is still showing as vulnerable.

First, attempt to forcibly reinstall the affected packages:

apt-get install --reinstall libssl1.0.0

If that fails, try forcing the complete removal of the package without involving any of Apt's dependency management and sanity checks:

dpkg --force-all --remove libssl1.0.0

At this point, the system is effectively 'broken' because libssl is missing and many packages are still installed that depend on it (this is what Apt tries so hard to prevent, and the reason we are going behind Apt's back), so reinstall libssl1.0.0, re-downloading the latest package from the repository:

apt-get clean && apt-get install libssl1.0.0

Alternatively, if you have downloaded the known good deb package, you can use dpkg to install and force overwrite of any existing files:

dpkg --force-overwrite -i libssl1.0.0_1.0.1-4ubuntu5.12_amd64.deb

Re-test and check (debsums, sha1sum) the installed files against known good configuration.

  • Exactly right, and now it passes the Heartbleed test. Thanks so much! Apr 14, 2014 at 13:16

If your apt-get repositories don't contains any precompiled 1.0.1g OpenSSL version, so just download sources from official website and compile it.

Below the single command line to compiling and install the last openssl version.

curl https://www.openssl.org/source/openssl-1.0.1g.tar.gz | tar xz && cd openssl-1.0.1g && sudo ./config && sudo make && sudo make install

Replace old openssl binary file by the new one via a symlink.

sudo ln -sf /usr/local/ssl/bin/openssl `which openssl`

You are all good !

# openssl version should return
openssl version
OpenSSL 1.0.1g 7 Apr 2014

Cf this blog post.

NB: As stated in the blog post, this workaround will not fix "Nginx and Apache server who have to be recompile with 1.0.1g openSSL sources."

  • Yes that's a great and simple workaround. The thing is, I know the binaries are available since the upgrade worked on Wednesday for my identical server. I thought perhaps that Ubuntu pulled it from the repository. Apr 12, 2014 at 14:00

Maybe you have 2 versions of OpenSSL in your PATH. This can happen, if you compiled your own version.

Try this /usr/bin/openssl version.

This schould be the position of the package version of OpenSSL.

  • Thanks for the reply. I did what you suggested (with -a) an got the same build date response. I have avoided compiling my own version of anything, as I need these servers to be easily-reproducible. Apr 12, 2014 at 15:35
  • @user1182988 - I assume transferring the files from the working sever isn't an option?
    – Ramhound
    Apr 12, 2014 at 17:23
  • Transferring the files is a viable option, but I'm concerned that the apt-get won't work. Apr 13, 2014 at 2:15

You need to update libssl1.0.0, then reboot your server. It will not work without a reboot.

  • Thanks for the reply! I tried apt-get purge libssl1.0.0, reboot, apt-get install libssl1.0.0, reboot - same version as above. Tried the same thing using openssl, still same version and build mentioned above. This is weird! Apr 13, 2014 at 2:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.