Resolved Plesk PHP 7.2.* OpenSSL Setup

[learning_curve]

We don't use the CentOS supplied PHP 5.4.* at all. We (currently) only use PHP 7.2.5 supplied by Plesk on all domains. Not had any issues or problems with it (or PHP 7.1.* in the past either) Nice! However... PHP & OpenSSL

The supplied PHP 7.2.5 is compiled by Plesk using OpenSSL 1.0.1e-fips - Feb 2013! (see image) As lots of previous PHP versions have been too. Well they are on Plesk 17.5.3 anyway. If you're on 17.8.11 please let us know if it's different.

Also within the same Plesk supplied PHP 7.2.5 is this specification line:

Registered Stream Socket Transports  -  tcp, udp, unix, udg, ssl, sslv3, tls, tlsv1.0, tlsv1.1, tlsv1.2

We want to remove the ssl, sslv3, tls, tlsv1.0 and preferably even tlsv1.1 too leaving only tlsv1.2 (like the rest of our server). Hence we're starting with the connection to the OpenSSL version that the Plesk supplied PHP 7.2.5 is using...

We've searched before posting this, but our conclusion is that Plesk are not going to change this anytime soon (we think)

So the only options we can see to achieve this are:

a) Re-compile PHP 7.2.5 ourselves and run that - Should be fine, but updates / upgrades could then become labour intensive and this therefore defeats the object (unless we choose to stay at PHP 7.2.5 by default for a long time)

b) Install a separate OpenSSL PHP Extension, configure this to use our current OpenSSL (1.1.0h) etc and invoke this via php.ini. Not completely sure this will work yet, but maybe somebody has already tried this? If / when working correctly, the separate OpenSSL PHP Extension would run instead of the current setup and therefore, the future Plesk PHP upgrades would be unaffected. It's easy to isolate / remove the php.ini data and/or rework the separate extension if needed.

c) Using another method that we don't know enough about - yet. If you do know of one, please advise

Any other thoughts, comments are welcome.

 

[Brujo]

The supplied PHP 7.2.5 is compiled by Plesk using OpenSSL 1.0.1e-fips - Feb 2013! (see image) As lots of previous PHP versions have been too. Well they are on Plesk 17.5.3 anyway. If you're on 17.8.11 please let us know if it's different.

nope is still the same OpenSSL 1.0.1e-fips - Feb 2013
CentOS Linux 7.5.1804 (Core)‬
Product Plesk Onyx Version 17.8.11 Update #7
PHP Version 7.2.5

 

[learning_curve]

nope is still the same OpenSSL 1.0.1e-fips - Feb 2013
CentOS Linux 7.5.1804 (Core)‬
Product Plesk Onyx Version 17.8.11 Update #7
PHP Version 7.2.5

Hmmmmm That's surprising as 17.8.11 is the latest Plesk release

 

[learning_curve]

Having investigated quite a lot more, OpensSSL 1.0.1e-fips does (just about...) support TLSv1.2 yes, but it's many, many major bug fixes behind and official support ceased way back in December 2016

Why would Plesk have gone through all the hard work of providing reliable PHP releases with regular version updates yet, appear to have completely missed this section when compiling....? We're guessing there's a valid reason (anybody from Plesk - can you comment / advise?) but seeing as Plesk Onyx Version 17.8.11 Update #7 i.e. the latest, most up to date Plesk Onyx release, is STILL providing this by default (^^ thanks @Brujo) this is puzzling.

Arguably, depending on individual server setups, if you're using Nginx as a proxy, then this can be completely hidden from view / usage / risk etc so many Plesk users may not care anyway, but not all Plesk users do that, so that's why a Plesk comment would be useful here, before we start on trying to solve it

 

[Brujo]

@learning_curve well it seems to be dependent of the OS where Plesk is running on.
OS ‪Ubuntu 16.04.4 LTS‬
Product Plesk Onyx Version 17.5.3 Update #47
PHP Version 7.2.5 - here it is OpenSSL Library Version OpenSSL 1.0.2g 1 Mar 2016

 

[AYamshanov]

Hi all,

Plesk does not provide OpenSSL. It's installed from OS repos (openssl on RHEL7 - Red Hat Customer Portal) and dynamically links with PHP.

As an example, I have deployed new instance in Cloud with Plesk 17.8.11 on CentOS 7.x:

# plesk version
Product version: Plesk Onyx 17.8.11 Update #7
   Update date: 2018/05/14 03:08
    Build date: 2018/05/03 11:30
    OS version: CentOS 7.5.1804
      Revision: c3fb546fb867ac424d65da14d8b023f11ec0d150
  Architecture: 64-bit
Wrapper version: 1.2

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

# rpm -qf /lib64/libssl.so.10
openssl-libs-1.0.2k-12.el7.x86_64

P.S. How to check what OpenSSL version is used by a domain/server?

P.P.S.

# ldd /opt/plesk/php/7.2/bin/php | awk '/libssl/ { system("rpm -qf "$3)}'
openssl-libs-1.0.2k-12.el7.x86_64

# ldd /opt/plesk/php/7.1/bin/php | awk '/libssl/ { system("rpm -qf "$3)}'
openssl-libs-1.0.2k-12.el7.x86_64

# ldd /opt/plesk/php/7.0/bin/php | awk '/libssl/ { system("rpm -qf "$3)}'
openssl-libs-1.0.2k-12.el7.x86_64

# ldd /opt/plesk/php/5.6/bin/php | awk '/libssl/ { system("rpm -qf "$3)}'
openssl-libs-1.0.2k-12.el7.x86_64

# ldd /usr/bin/php | awk '/libssl/ { system("rpm -qf "$3)}'
openssl-libs-1.0.2k-12.el7.x86_64

 

[AYamshanov]

7.4 Release Notes:
- openssl rebased to version 1.0.2 (Chapter 15. Security - Red Hat Customer Portal)

---

If you have access to RedHat KB articles, you may additionally read "phpinfo() does not showing up correct openssl info after upgrade openssl via yum - Red Hat Customer Portal" article.

 

[learning_curve]

@learning_curve....well it seems to be dependent of the OS where Plesk is running on....

Yes and No The different OpenSSL releases on different OS Plesk package releases has happened before (linked to something we were investigating back then) and THIS thread opening thread post (not by us) illustrates that...

....Plesk does not provide OpenSSL. It's installed from OS repos

Yes, agreed, but we're not referring to that, we're referring to the compiled PHP supplied by Plesk and the OpenSSL version / link / referrral contained within it by default

....and dynamically links with PHP

Now this is far more relevant. Could you explain how this is done please? In our case for example, we don't have any existence of OpensSSL 1.0.1e-fips anywhere at all on our server.... So how can our PHP 7.2.5 be dynamically linked to something that is non-existent without showing any errors?

P.S. How to check what OpenSSL version is used by a domain/server?

Yes we have already seen this too and the bottom section (shown below) is real life and part of this whole query

Additional Information
Displayed OpenSSL version in Plesk > Domains > example.com > PHP Settings >phpinfo() could differ from the one used by Plesk PHP. The reason for that is that information about OpenSSL in phpinfo() is added to php-binary on compilation stage

New posts as fast as we are typing...

....If you have access to RedHat KB articles, you may additionally read.....

Currently we don't Could that be posted on here if you do? Thanks for your involvment so far regardless!

This may 'possibly' explain the previous two quotes/ comments depending on what it says... For example if the php.ini file releates to being complied by Plesk using OpensSSL 1.0.1e-fips but in fact, it's dynamically linked (in our case) to OpenSSL 1.1.0h than that's great progress, albeit quite confusing and hidden unless you have suddenly just become aware via this forum

 

[learning_curve]

Update: Meantime, working on your helpful last few posts @AYamshanov we're at the stage of a reasonably educated guess now

We're now guessing that the article you may post, explains in detail the mis-information provided by php.ini and may lead towards understanding the dynamic link that you may be able to explain in more detail on here.

Working on our last posted example (assumption) and running the ssh queries you did plus a couple of extra ones, (below) It appears that regardless of what Plesk originally complied PHP with, the dynamic link is to the current Vendor OS supplied Openssl (CentOS - openssl-1.0.2k-12.el7.x86_64 - in our case). That's correct eh?

If you're runing a self-upgraded OpenSSL (as we are) then this will be ignored UNLESS, the dynamic link is altered / updated / re-worked etc. That's also correct eh?

# plesk version
Product version: Plesk Onyx 17.5.3 Update #47
    Update date: 2018/05/08 09:39
     Build date: 2017/03/17 16:00
     OS version: CentOS 7.5.1804
       Revision: 55d1b49a272f44666e1920eca8b6e4da449a38cd
   Architecture: 64-bit
Wrapper version: 1.2

# openssl version
OpenSSL 1.1.0h  27 Mar 2018

# rpm -qa | grep -i openssl
perl-Crypt-OpenSSL-Random-0.04-21.el7.x86_64
perl-Crypt-OpenSSL-Bignum-0.04-18.el7.x86_64
perl-Crypt-OpenSSL-RSA-0.28-7.el7.x86_64
xmlsec1-openssl-1.2.20-7.el7_4.x86_64
openssl-devel-1.0.2k-12.el7.x86_64
openssl-libs-1.0.2k-12.el7.x86_64
openssl-1.0.2k-12.el7.x86_64

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

# rpm -qf /lib64/libssl.so.10
openssl-libs-1.0.2k-12.el7.x86_64

 

[AYamshanov]

Our build environment uses OpenSSL 1.0.1e-fips, but this OpenSSL not compiled into PHP. PHP uses installed OpenSSL library from your system. A small how-to about how shared libs work: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html.

Quotes from KB:

If the php package was not rebuilt against the new OpenSSL version it
will still show the old version although in reality it uses the new
version.

This is achieved by versioned symbols and it was necessary to add this
due to some applications incorrectly comparing the library and header
version strings and bailing out if these weren't the same.

There is no way to workaround the issue except rebuilding the php
against the new OpenSSL. However the issue is just a cosmetic thing and
they should ignore it.

1. We can ignore the info from phpinfo()
2. We can update php package to [...] or high version.

I hope this cosmetic issue will be fixed in future with one of micro-update, but anyway it is a cosmetic thing.

 

[learning_curve]

Thanks for the update @AYamshanov That does still leave the odd unanswered question but...

...Our build environment uses OpenSSL 1.0.1e-fips, but this OpenSSL not compiled into PHP. PHP uses installed OpenSSL library from your system. A small how-to about how shared libs work: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html ...

That's not a 100% clear answer but, we're pretty sure what you're saying is;

'...Yes when suppplying a PHP package to CentOS 7 users, it is complied by Plesk using OpenSSL 1.0.1e-fips BUT that's actually irrelevant, because, once the PHP package is installed on the Plesk user's server running on CentOS 7, the OpenSSL actually used for PHP, is the CentOS repos version (Openssl-1.0.2k-12.el7.x86_64 in the previous example) and this is accessed by PHP via your previously mentioned "dynamic link" aka "shared library"

Is that correct? It's what we effectively said in Post #9 above but that does make good sense to us now.

I hope this cosmetic issue will be fixed in future with one of micro-update, but anyway it is a cosmetic thing

A future cosmetic issue fix sounds fine.
Far more important is what we have now, which is a clear understandsing of the real situation. Thank you.

In terms of our original question (at the start of this thread) which is now updated after your posts, then the answer (if we for example, wish PHP to use Openssl-1.1.0h and not Openssl-1.0.2k as it currently is doing) is to change the shared library identity or, find a specific set of repros that can replace the current set of Openssl CentOS repros. We think that's correct?

The OpenSSL version is important (to us) because, as explained in other threads, many e-commerce card payment processers will now only work using TLSv1.2. Yes OpenSSL 1.0.1e-fips can still support that, but it also still supports outdated and now 'unsafe' previous verions, like SSLv3 and TLSv1.0 No doubt this will change again once TLSv1.3 is officially released too...

 

[AYamshanov]

learning_curve, could you provide steps how you are compiling your own OpenSSL 1.1.0h? I will try to reproduce your environment. Anyway, you didn't have openssl-1.1.0h package in your system and, as you show, it not replaced system's libssl.so.10. IMHO, the question is more about Linux, system administration and programming rather than about Plesk.

And you needn't recompile OpenSSL if you want to disable one of protocol, you can do it in conf-file of web-server: [How to] Disable TLSv1.1?

 

[learning_curve]

learning_curve, could you provide steps how you are compiling your own OpenSSL 1.1.0h? I will try to reproduce your environment

Sure and thanks a lot for your extra involvement!

We chose this OpenSSL 1.1.0h release, because, it was the most current, stable release, that was available at the time we were running a script to change many other things, including Nginx. This was part of a great, updated script (not ours, one that is provided here on the forum) but one which we modified slightly too, after trialing it a few times.

A quick note, prior to the link below, the existing /usr/share/openssl that's referred to, was OpenSSL 1.1.1-dev which provided TLSv1.3 draft 18 support and whilst fine for a while, was then quickly depreciated. Hence we put back all the TLSv1.3 work until it was released officially (anytime soon we believe...) This dev release, came from a great tutorial which is also here on the forum.

It's a long thread but the most relevant, summary post c/w all the OpenSSL compilation details that you asked for and including the forum links to the script & the tutorial that we mentioned (if you need them) is HERE

Anyway, you didn't have openssl-1.1.0h package in your system and, as you show, it not replaced system's libssl.so.10. IMHO, the question is more about Linux, system administration and programming rather than about Plesk

Yes totally agree. That's mainly because it's become clear now as to how PHP was utilising OPenSSL within a Plesk setup which has (happily) led onto this

Off topic slightly, but we've seen similar to this before (see below) back when we updated sw-cp-server i.e. both releases (rpm and customised) are still present, but no problems have ever occured (and we're still running our updated sw-cp-server now and will carry on doing, until Plesk release a TLSv1.3 version - maybe later this year )

For your reference, this is explained in THIS seperate thread which includes the great step-by-step set of instructions posted by another forum member, which we sucessfully ran to update sw-cp-server - mainly in order to allow even more security (cipher curves in this case) It's not such a long thread, has a clear result and the step-by-step instructions are very clear.

# sw-cp-serverd -V
nginx version: nginx/1.11.10
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled....

# sw-cp-serverd -V
nginx version: nginx/1.12.1
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)
built with OpenSSL 1.0.2l  25 May 2017
TLS SNI support enabled....

And you needn't recompile OpenSSL if you want to disable one of protocol, you can do it in conf-file of web-server: [How to] Disable TLSv1.1?

Yes we know this thanks. All our protocols, in all the relevant places (nginx / apache / sw-cp-server etc are indeed TLSv1.2 only already. However, it's not just disabling the old protocols, that's the driver here. It's also things like we've already seen; e.g. ability to support all current cipher curves, ability to support third party connections (where minimum specs e.g. Nginx release / OpenSSL release / TLS release etc are required and checked before allowing connections.

Apologies for the long reply / reading assignment but we wanted to fully answer your post

 

[learning_curve]

....could you provide steps how you are compiling your own OpenSSL 1.1.0h? I will try to reproduce your environment....

Any feedback on this experiment / simulation @AYamshanov ?
We're happy to wait for any findings or comments you have first, before we proceed ourselves

 

[AYamshanov]

Sorry for the delay, I was out-of-office since Tuesday.

In OpenSSL v1.1.x, a name of libssl library was changed to "libssl.so.1.1", this is the usual way to show that the new library differs from the previous one. PHP in Plesk requires default library (libssl.so.10) that shipped/supported by OS vendor:

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

I don't know a beautiful way how to get around this.

 

[learning_curve]

...I don't know a beautiful way how to get around this.

Thanks for the update. More to follow...

 

[learning_curve]

A Re-Think...

Both libssl.so.10 and libssl.so.1.1 exist on our server (see previous posts as to why):

libssl.so.10  >>>  /usr/lib64/libssl.so.10
libssl.so.1.1 >>>  /usr/local/openssl/lib/libssl.so.1.1

Having investigated a little further, we've seen others correct various PHP / OpenSSL errors that they themselves had created. That's not the same circumstances as this 'challenge' but one of the different methods that's common in all of the various corrective actions people took, may possibly work here? The 'fixes' all involved the correction / alteration / change of symlinks...

Here is an example extract:

There is no command to retarget a symbolic link, all you can do is remove it and create another one. Assuming you have GNU utilities (e.g. under non-embedded Linux or Cygwin), you can use the -lname primary of find to match symbolic links by their target, and readlink to read the contents of the link. Untested:

find /mnt/home/someone/something -lname '/home/someone/*' \
    -exec sh -c 'ln -snf "/mnt$(readlink "$0")" "$0"' {} \;

Here is another example extract:

I somehow got my symlinks corrupted when installing a newer version of OpenSSL. To fix this situation, I fixed my symlinks in /usr/lib64. E.g.

sudo ln -sf libssl.so.0.9.8e libssl.so.10

...I don't know a beautiful way how to get around this.

Obvioulsy we're still investigating and the eventual solution we agree, may not be beautiful but running PHP 7.2.* on an old release OpenSSL 1.0.2.k whilst currently seeing that incorrectly being displayed as OpenSSL 1.0.1e-fips due to a 'cosmetic' system error, is far from a 'beautiful' situation anyway We'll keep digging and update as we trial / test different things....

 

[learning_curve]

Going back to this, your last post @AYamshanov on this thread and after more reading by us;

In OpenSSL v1.1.x, a name of libssl library was changed to "libssl.so.1.1", this is the usual way to show that the new library differs from the previous one. PHP in Plesk requires default library (libssl.so.10) that shipped/supported by OS vendor:

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

I don't know a beautiful way how to get around this.

The information you have shown above re: libssl.so.10 is taken from within the /opt/plesk/php/7.2/bin/php binary file itself. We're assuming that the PHP requirement for an libssl library is met, by a request being sent to /lib64/libssl.so.10 (as that's the CentOS / Yum Updated version on our server), but this is actually, just a symlink to /usr/lib64/libssl.so.1.0.2k (binary file) for the same CentOS reasons. Indeed /usr/lib64/libssl.so which is also present, is another symlink to /usr/lib64/libssl.so.1.0.2k which is the true requirement anyway in both cases.

Obviously we can't easily change the /opt/plesk/php/7.2/bin/php binary file (well we can, but it's a lot of recompiling work and would be replaced by the next PHP upgrade anyway, so we haven't) but, as shown earlier, we do also have libssl.so.1.1 which in theory could be used by PHP7.2 and which is located here: /usr/local/openssl/lib/

Edited / Updated

So...we gave that a try but somewhat predictably and as per your post to be fair, doesn't work as easily as imagined...

[root@root] lib64]# ls -la libssl.so
lrwxrwxrwx. 1 root root 16 May 11 03:31 libssl.so -> libssl.so.1.0.2k
[root@root] lib64]# ls -la libssl.so.10
lrwxrwxrwx. 1 root root 16 May 11 03:29 libssl.so.10 -> libssl.so.1.0.2k
[root@root] lib64]# ldd /opt/plesk/php/7.2/bin/php | awk '/libssl/ { system("rpm -qf "$3)}'
openssl-libs-1.0.2k-12.el7.x86_64

[root@root] lib64]# ln -sf /usr/local/openssl/lib/libssl.so.1.1 libssl.so
[root@root] lib64]# ln -sf /usr/local/openssl/lib/libssl.so.1.1 libssl.so.10
[root@root] lib64]# ls -la libssl.so
lrwxrwxrwx. 1 root root 36 Jul 3 01:54 libssl.so -> /usr/local/openssl/lib/libssl.so.1.1
[root@root] lib64]# ls -la libssl.so.10
lrwxrwxrwx. 1 root root 36 Jul 3 01:54 libssl.so.10 -> /usr/local/openssl/lib/libssl.so.1.1
[root@root] lib64]# ldd /opt/plesk/php/7.2/bin/php | awk '/libssl/ { system("rpm -qf "$3)}'
/opt/plesk/php/7.2/bin/php: /lib64/libssl.so.10: version `libssl.so.10' not found (required by /opt/plesk/php/7.2/bin/php)
openssl-libs-1.0.2k-12.el7.x86_64

[root@root] lib64]# ln -sf libssl.so.1.0.2k libssl.so
[root@root] lib64]# ln -sf libssl.so.1.0.2k libssl.so.10
[root@root] lib64]# ls -la libssl.so
lrwxrwxrwx. 1 root root 16 Jul 3 01:51 libssl.so -> libssl.so.1.0.2k
[root@root] lib64]# ls -la libssl.so.10
lrwxrwxrwx. 1 root root 16 Jul 3 01:52 libssl.so.10 -> libssl.so.1.0.2k

Using LD_LIBRARY_PATH is a possible answer, but that's more involved at this stage for our desired end result.

FWIW OpenSSL 1.1.0h (which NGINX is running on in our case) is deliberately separate from the CentOS provided OpenSSL 1.0.2k mainly because of the extra work configuring Yum updates etc. Plus it's unlikely, but possible that some other services may not (yet) be fully functional with OpenSSL 1.1.0h.

 

[learning_curve]

Last post was edited / updated and so our revised plan (for this) is as follows:

1) Investigate why edited / updated symlinks didn't work here (mainly for our own knowledge...)
2) Suspend this issue meantime, until we have upgraded Plesk from 17.5.3. to 17.8.11 and ensured all other items are still fully functional
3) Then go back to this again, with either; a) a re-workable answer to 1) or b) using OpenSSL 1.1.0h exclusively (CentOS overwrite / Yum upgrade mods etc) not as well as OpenSSL 1.0.2k on our server, as it is currently.

The future switch over to TLSv1.3 (in terms of OpenSSL upgrades) will be much, much easier if we are already using OpenSSL 1.1.0h exclusively, so that may be the final answer, because this would also in theory solve this Plesk/PHP/OpenSSL problem too

 

[learning_curve]

To close this thread... From the ^^ above final choices, we chose option 4)

Option 4) is new cloud server, with a clean install of Ubuntu 18.04.01 and a clean install of Plesk 17.8.11#16 and then subsequent additional mods.

We're now 'swapping' everything over from our CentOS7 / Plesk 17.5.3 cloud sever on to its Ubuntu replacement, testing everything, taking the new Ubunto server live and then deleting the old CentOS7 server.

We've already checked / tested all the PHP specific questions that we've asked in this thread and ( for us anyway @AYamshanov ) the new server / spec completely solves all the problems