Hello Alfred, I encountered the same error while installing GLPI (PHP Curl is an "optional" required PHP extensions) on Uniform Server 13.4.0. To solve I did this :
Check file version from path (apache2) : ..\UniServerZ\core\apache2\bin
Check file version from path (php73) : ..\UniServerZ\core\php73
File / Apache2 bin / PHP73
libcrypto-1_1.dll : 18.104.22.168 | 22.214.171.124
libcrypto-1_1-x64.dll : |
libcurl.dll : |
libsasl.dll : | 126.96.36.199
libssh2.dll : | existing (unknown version)
libssl-1_1.dll : 188.8.131.52 | 184.108.40.206
libssl-1_1-x64.dll : |
nghttp2.dll : 220.127.116.11 | 18.104.22.168
libeay32.dll : 22.214.171.124 |
ssleay32.dll : 126.96.36.199 |
Solution is to copy (most recent version) files libcrypto-1_1.dll and libssl-1_1.dll from ..\UniServerZ\core\php73 to ..\UniServerZ\core\apache2\bin directories.
Then the curl extension seems to be ok (at least, well enough, to fulfill the GLPI installation requirements). How do you check the curl extension is "really" working ? (i guess the GLPI installation just check it is "available") The posts I read from :
Source : https://stackoverflow.com/questions/16424117/php-unable-to-load-php-curl-dll-extension
Chris Tsirkas, Jul 11 2018 at 14:13
Usually this is an OpenSSL version mismatch error, between Apache and PHP.
In case Apache loads PHP as a DSO module, its own OpenSSL versions (dlls and libs) will be used.
So, in case the PHP extension requires a newer version, it may not find the appropriate interface inside the Apache-loaded DLLS and it will fail to work.
Since you need the PHP extension to load, you need the relevant DLL files to be at least the version of what the PHP module asks for.
Supposing that you 're using lastest builds for both Apache and PHP and both having been built with the same MVC version, you can copy the following files:
libeay32.dll (if existing in your PHP distribution)
ssleay32.dll (if existing in your PHP distribution)
from the PHP root folder to the Apache2/bin folder, in case you 're confident that the PHP build is newer than the Apache build.
In the opposite case, you can copy the same files from the Apache BIN to the PHP root.
In any case, backup the contents of the APache and PHP folders beforehand.
Adding the PHP path as an enviromental variable will give priority to this path for loading the relevant DLLs and may solve the problem.
However, you lose in server portability.
Additionally, if you have also added the Apache PATH as a variable and the OpenSSL versions are way different (up to loading different linked DLL files), a lot of shit may happen.
Rusty Fausak, Jul 28 2018 at 5:34
I had to copy over libssl-1_1.dll and libcrypto-1_1.dll from my php7.2.8/ext folder to apache2.4.23/bin folder to get this to work.
Before that, I was receiving "Unable to load dynamic library" on php_curl.dll and php_openssl.dll despite those files existing in the correct place.