I have inherited a server in one of our Dev environments and found out straight away that it was not patched when the heartbleed was discovered.

Now, I've upgraded it - including all SSL libraries and I've regenerated self signed certificates, yet even after full server reboot it still shows up as vulnerable against various Heartbleed checkers.

This is the state of the things. Ubuntu/Kernel version:

root@server:~# uname -a
Linux server.domain.com 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

OpenSSL lib version:

root@server:~# dpkg -l|grep ssl
ii  libio-socket-ssl-perl            1.53-1                            Perl module implementing object oriented interface to SSL sockets
ii  libnet-ssleay-perl               1.42-1build1                      Perl module for Secure Sockets Layer (SSL)
ii  libssl1.0.0                      1.0.1-4ubuntu5.13                 SSL shared libraries
ii  openssl                          1.0.1-4ubuntu5.13                 Secure Socket Layer (SSL) binary and related cryptographic tools
ii  python-openssl                   0.12-1ubuntu2.1                   Python wrapper around the OpenSSL library

OpenSSL build:

root@server:~# openssl version -b
built on: Fri May  2 20:24:44 UTC 2014

/etc/issue contains some stuff from cloud-sigma where the server is hosted.

Anyone has any idea how to take this further ?


  • 1
    https service or other? if you're talking about, for example an nginx server, you'd need to update that aswell – pete May 9 '14 at 17:01
  • 4
    What web server are you running? Is 1.0.1-4ubuntu5.13 the patched version of openSSL? Is your web server even using the system openSSL libraries, or does it have its own libraries built-in? Have you restarted the web server or even gone whole-hog and done a full reboot since upgrading openSSL to be sure the new shared libraries are loaded by the web server using them? – jayhendren May 9 '14 at 17:01

You should run the ldd script against the actual webserver binary. Your webserver, especially if it's a proprietary one, might be statically linked, or loading your libraries from an odd directory. An example of how to check Apache on CentOS:

# ldd /usr/sbin/httpd
    libssl.so.6 => /lib64/libssl.so.6 (0x00002b94ab034000)

# yum whatprovides libssl.so.6
Loaded plugins: dellsysid, security
openssl-0.9.8b-10.el5.i686 : The OpenSSL toolkit
Repo        : base
Matched from:
Other       : libssl.so.6
  • This is a good answer, and probably the easiest way to check what version of openSSL the webserver is loading. – jayhendren May 9 '14 at 18:10
  • or look in the webserver logs ... – mdpc May 10 '14 at 5:12

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.