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…” 
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 
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
