-1

I have upgraded the openssl version on my server to the latest version of openssl but the libraries that the reverse proxy server is using is pointing to .

  strings /usr/lib64/libssl.so.10 | grep "^OpenSSL "

  OpenSSL 1.0.1e-fips 11 Feb 2013

Where as when i type command

openssl version

it shows

   [root@newreverseproxy openssl-1.0.2]# openssl version   
   OpenSSL 1.0.2 22 Jan 2015

I need my reverse proxy server nginx to use the up to date version of OpenSSL would really appreciate if some one could help me up with it .

MadHatter
  • 79,770
  • 20
  • 184
  • 232
zeemz
  • 109
  • 2
    Don't run an unregistered version of RH; use CentOS instead, then you won't have an access-to-patches problem. Also, *why* do you need your nginx to run against the latest OpenSSL? – MadHatter Feb 18 '15 at 08:21

2 Answers2

1

the 'problem' is that your ngnix is linked against a particular verion of libssl (libssl.so.10) ... your newly compiled libssl has a different version. Run 

ldd `which openssl`

to see which version it is ...

In order for ngnix to use the new version of libssl you have to recompile ngnix as well.

Another option you have is to compile openssl-1.0.1l.tar.gz, which is the latest version of the 1.0.1 line of the software. The resulting libssl will be compatible with 1.0.1e and can be readily used by your existing ngnix binary.

If you are replacing libssl with a newer version, note that this is a rather 'risky' business since many applications use libssl, so better be sure that it works, or many programs may fail to even start.

A nice way to just replace libssl for ngnix, is to install the new libssl into an alternate directroy and then start ngnix with the environment variable LD_LIBRARY_PATH pointing to the new directory. Just make sure the newly compiled library is called exactly the same as the one you find when running ldd on ngnix

export LD_LIBRARY_PATH=/usr/local/new-libssl/lib
ngnix -whatever-options-you-want
Tobi Oetiker
  • 1,842
  • 13
  • 12
0

As well as Tobi's suggestion about openssl versions, you may not be installing the libraries into the correct locations. If you just run "./configure; make; make install" it will install into /usr/local/lib by default, for example. Even if you set the prefix properly, you might still be installing into /usr/lib/ rather than /usr/lib64, and ldconfig might not be set up properly

However, your distribution almost certainly has updated libraries available that do not involve compilation. Hand-compiling openssl now more or less commits you to hand-compiling it from now on, so this is really a last-resort method. No offence intended here, but if you're having problems getting this to work, it's not the right approach, at least not on a server you care about.

If you are running RedHat, CentOS, Fedora or any other distro that uses .rpm packages, try running 'sudo yum update'. If you are running debian, ubuntu, mint or any other distro that uses .deb packages, try running 'sudo apt-get update; sudo apt-get dist-upgrade'. If you need more help here, try googling for how to update your distro - there are heaps of people posting articles on how to upgrade various linux distributions for GHOST or Heartbleed or poodle, so one of those will have instructions you can use.

Daniel Lawson
  • 5,476
  • 22
  • 27
  • Agreed , But the irony is that that system is not registered to RHN also no RHN repo is available not sure how to workaround from it. – zeemz Feb 18 '15 at 08:10