How To Use Different OpenSSL Shared Libraries


#1

Background: We have a cloud server, using CentOS 7.5 and Nginx 1.14.0 proxy for Apache 2.4.6 (RHEL 7 Backported) with OpenSSL 1.1.0h and TLSv1.2. We normally use Plesk to manage everything. Plesk provide PHP and all its updates (we’re currently using PHP7.2.8) but… the OpenSSL setup in Plesk provided PHP, is dynamically linked to the OS currently in use and all of it’s associated shared libraries. In our case, CentOS 7.5 is still using OpenSSL 1.0.2k which has some security and other future limitations, for example; no future, simple, easy upgrade to OpenSSL 1.1.1 (which OpenSSL 1.1.0h does have) in order to use TLSv1.3 as soon as it’s released.

We’ve retained all the CentOS installations and default setups (these are still regularly updated via YUM) but we re-configured all other items to use OpenSSL 1.1.0h and TLSv1.2 ourselves without any issues.

Our challenge now, is to switch the OpenSSL shared libraries that the Plesk provided PHP uses, especially as Plesk’s unofficial advise was “…there’s no easy way to do this. Wait for CentOS to catch up and it will be fine…” :sweat_smile: Whilst that’s very true of course, CentOS won’t be catching up anytime soon we think, as historically, their approach has always been (justifiably?) cautious in this area of upgrades

Our Plesk provided PHP installation is currently using these shared libraries: libssl.so.10

ldd /opt/plesk/php/7.2/bin/php | grep ssl
libssl.so.10 => /lib64/libssl.so.10 (0x00007f08ad523000)

find / -name libssl.so.10
/var/www/vhosts/chroot/usr/lib64/libssl.so.10
/usr/lib64/libssl.so.10

libssl.so.10 is a dynamic link to /usr/lib64/libssl.so.10 which itself, is a dynamic link to /usr/lib64/libssl.so.1.0.2k which takes us back to our challenge / where we started i.e. how do we change final destination to be this: usr/local/openssl/lib/libssl.so.1.1 which some may say is not really a specific PHP question but, we’re asking anyway :smiley:

FWIW /var/www/vhosts/chroot/usr/lib64/libssl.so.10 isn’t used by us as we don’t need to chroot any subscriptions

We can’t simply replace the dynamic link (we’ve already tried that but this simply produces an error because the end result (name) is not what is expected / required. We haven’t tried a file replace & rename method as that’s fraught with other possible consequences…

As far as we understand… we could either:

a) Re-compile PHP ourselves, but that would mean lots of re-compiling every time there is a new PHP upgrade, so it’s far from ideal

b) Work with LD_LIBRARY_PATH which in theory… is only for de-bugging, but could / should work if we work through it slowly and patiently. Again not ideal

c) Change our cloud server from CentOS to Debian 9 or Ubuntu 18.04 which would by default solve this problem (and which we might do anyway for other reasons)

d) Another, more efficient approach (e.g. php.ini / separate extension use etc) that we are currently unaware of or have little knowledge of…

Any comments are more than welcome


#2

Short answer, start using Debian and dont hate yourself for not doing it sooner. CentOS will NEVER catch up. They have ALWAYS been behind and always will be. FYI, Ubuntu’s base is Debian.


#3

Debian is better than RHEL? LOL


#4

I will pass on the strawman argument. Nothing was said about which is better. What I stated are just facts.

  1. CentOS is always behind. (OP’s problem is a direct result of this. i.e, default Php version is 5.4 )
  2. CentOS will never be current
  3. Ubuntu’s base is Debian

#5

Yes, our original question was esentiallly, to see if there was any quick, clever solution within PHP that we were unaware of. It’s been answered now, because there isn’t :rofl: :rofl:

Agree totally on CentOS, as you can see in our original post. We did know about the Debian/Ubuntu relationship, but appreciate all the comments. RHEL 7 was a possible option, but even allowing for backporting, that too, isn’t always quick to update (e.g. with some things like OpenSSL)

FWIW we will now swap everyting over to a new cloud server and run everything on Ubuntu 18.04.1 plus upgraded packages. For us, that should be this particular problem; solved.