"php 5.x, 7.x and 8.0 cannot compile against openssl 3.0 or higher. Try php 8.1 or higher"

InTheWoods

InTheWoods

Verified User
Joined
Dec 31, 2020
Messages
45
Location
Internet
Tried CloudLinux, AlmaLinux 8.x and Debian 12. All give the same error when trying to enable PHP multi-choice versions 7.4 or 8.0. I have older DirectAdmin servers running CloudLinux without this being an issue, but would like newer deployments to have the latest OS.

While 8.x support is great, many would still prefer to be able to use 7.4 as well. Is this simply not possible with the latest OS releases? Is this a DirectAdmin thing or more likely, a PHP / OpenSSL thing? Is there any option for running OpenSSL 3.x with PHP 7.4 as well?

And in case you found this thread via Google, general note for reference if you need to install an OS specifically for OpenSSL 1.x:

The last versions of the specified OS distributions that use OpenSSL 1.x are as follows:
  • AlmaLinux: AlmaLinux 8.5 is the last version using OpenSSL 1.1.1 before transitioning to OpenSSL 3 in AlmaLinux 9
  • CentOS: CentOS 7 is the last version using OpenSSL 1.0.2k before transitioning to OpenSSL 1.1.1 in CentOS 8
  • Debian: Debian 11 (bullseye) is the last version using OpenSSL 1.1.1w before transitioning to OpenSSL 3.0 in Debian 12 (bookworm)
  • Ubuntu: Ubuntu 20.04 is the last version using OpenSSL 1.1.1 before transitioning to OpenSSL 3.0 in Ubuntu 22.04
Click to expand...
(Thanks ChatGPT for compiling that list faster than I could have looked it up manually)
 
InTheWoods said:
Tried CloudLinux, AlmaLinux 8.x and Debian 12.
Click to expand...
I think you mean AlmaLinux 9.x as Alma 8.x does not have issues at all using php 7.4.
So Almalinux 8.x will not give you the error you posted.

InTheWoods said:
Is there any option for running OpenSSL 3.x with PHP 7.4 as well?
Click to expand...
You can search for postings in the forums. There are 1 or 2 threads which show manual compilation of OpenSSL 1.x next to OpenSSL 3.0 on newer OS systems running OpenSSL 3.0 and then you can use them next to each other.
Use at your own risk.
 
FWIW I managed to install OpenSSL v1 and compile PHP on AlmaLinux 9.

Code: 
  wget https://www.openssl.org/source/openssl-1.1.1w.tar.gz
  tar -zxf openssl-1.1.1w.tar.gz 
  cd openssl-1.1.1w
  make clean
  ./config shared –prefix=/usr –openssldir=/usr/local/openssl
  make && make test
  make install
  openssl version # still shows v3
  /usr/local/bin/openssl version # shows v1
  mv /usr/bin/openssl /usr/bin/openssl-bak
  ln -s /usr/local/bin/openssl /usr/bin/openssl
  openssl version # now shows v1 and php compiles
 
Richard G said:
But is php 8.1 and 8.2 now also using 1.1.1w or is php 7.4 using 1.1.1w and 8.1 and 8.2 using openssl 3.x?
Click to expand...
Well, I assumed you were using `--openssl=/usr/local/openssl` in your compile script, hence it would be whichever that directory is currently at.
 
youds said:
Well, I assumed you were using
Click to expand...
I'm not using anything custom compiled yet, I was just asking.
Because I read somewhere (don't remembe where exactly) that openssl 1.1.1 when manually compiled next to openssl 3.0 must be in a seperate directory, so not the same 3.0 is using.

Since I see you moving the 3.0 binary file to .bak and symlinking to the 1.1.1w version, it highly doubt that both 1.1.1 and 3.0 can be running at the same time.
Which migh be important for others reading this, so they know then every php version is running 1.1.1w this way, for some this might not be an option.

I think there is a way to use both where php 7.x and 8.0 only used 1.1.1w and 8.1+ used 3.0, seen some solution for Debian somewhere. Maybe done via some custom thing which points php 7.x and 8.x to the correct openssl, but I don't know how it's done.
 
FYI, OpenSSL 1.1.1 is EOL now https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/

OpenSSL 1.1.1 was released on 11th September 2018, and so it will be considered EOL on 11th September 2023. It will no longer be receiving publicly available security fixes after that date.

If you got your copy of OpenSSL 1.1.1 from your Operating System vendor (e.g. via .rpm or .deb packages) or some other third party then the support periods that you can expect from them may differ to those provided by the OpenSSL Project itself. You should check with your OS vendor/other third party what support for OpenSSL you might expect from them.

If you downloaded your copy of OpenSSL direct from the OpenSSL project then we would strongly encourage you to plan an upgrade to a more recent version before 1.1.1 reaches its EOL date. Our most recent version is OpenSSL 3.1 which will be supported until 14th March 2025. Also available is OpenSSL 3.0 which is an LTS release and will be supported until 7th September 2026. Our migration guide provides some useful information on the issues you should be considering when upgrading.
Click to expand...
 
Zhenyapan said:
as php 5.x-7.x :sneaky: but some users want it and not ready to pay for cloudlinux
Click to expand...
For my non-Directadmin LEMP stack, I've backported all PHP 8+ security fixes into PHP 5.6 and 7.0, 7.1, 7.2, 7.3, 7.4 where applicable so they're still somewhat viable :)

Richard G said:
Exactly the reason why I wonder if this is the correct solution if Openssl 3.0 is not running next to 1.1.1w for PHP 8.1+.
I wouldn't use this anyway, or only for a short time.

Or indeed like @Zhenyapan said, pay for Cloudlinux.
Click to expand...
Yeah. For my non-Directadmin LEMP stack, I originally tried building custom RPMs for custom curl and OpenSSL 1.1.1 for EL9 just for PHP 7.4 and 8.0 support in EL9. Instead opted to patch my PHP 7.4 and 8.0 install routines to make it work with OpenSSL 3.0 on EL9 - using REMI EL9 PHP 8.0 repo based patches that RHEL 9 uses for their native PHP 7.4/8.0 + OpenSSL 3.0 support :D

Example PHP 8.0.30 compile on AlmaLinux 9.2 with OpenSSL 3.0 system library :cool:
Code: 
cat /etc/os-release
NAME="AlmaLinux"
VERSION="9.2 (Turquoise Kodkod)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.2"
PLATFORM_ID="platform:el9"
PRETTY_NAME="AlmaLinux 9.2 (Turquoise Kodkod)"
ANSI_COLOR="0;34"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:almalinux:almalinux:9::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"
ALMALINUX_MANTISBT_PROJECT="AlmaLinux-9"
ALMALINUX_MANTISBT_PROJECT_VERSION="9.2"
REDHAT_SUPPORT_PRODUCT="AlmaLinux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.2"
Code: 
php -v
PHP 8.0.30 (cli) (built: Oct 26 2023 10:56:45) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.30, Copyright (c) Zend Technologies
    with Zend OPcache v8.0.30, Copyright (c), by Zend Technologies
Code: 
php --ri openssl
openssl
OpenSSL support => enabled
OpenSSL Library Version => OpenSSL 3.0.7 1 Nov 2022
OpenSSL Header Version => OpenSSL 3.0.7 1 Nov 2022
Openssl default config => /etc/pki/tls/openssl.cnf
Directive => Local Value => Master Value
openssl.cafile => no value => no value
openssl.capath => no value => no value
Code: 
ldd $(which php) | grep crypt
        libcrypt.so.2 => /usr/lib64/../lib64/libcrypt.so.2 (0x00007f4a662de000)
        libk5crypto.so.3 => /usr/lib64/../lib64/libk5crypto.so.3 (0x00007f4a65e5f000)
        libcrypto.so.3 => /usr/lib64/../lib64/libcrypto.so.3 (0x00007f4a65200000)
        libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f4a624c7000)
 
Last edited:
You must log in or register to reply here.
Back
Top