I am running PHP 5.2.13 on a Windows Server 2008 R2 machine (Windows 7 equivalent).
I'm mostly writing this just because I get a google dead end on searching for the warning and I'm trying to add something for it.
I am getting the following notice / warning:
Use of undefined constant OPENSSL_ALGO_DSS1 - assumed 'OPENSSL_ALGO_DSS1'
openssl_verify() expects parameter 4 to be long, string given
When running this line of code:
return openssl_verify($data, $signature, $this->getPublicKey(), OPENSSL_ALGO_DSS1);
Obviously the second warning is caused by the first.
However the problem isn't that the OpenSSL library isn't loaded, as I have the following output from phpinfo:
OpenSSL support enabled
OpenSSL Version OpenSSL 0.9.8k 25 Mar 2009
This is working on all other machines that it has been tested on, so there is something machine specific.
The only difference I have spotted is the following from phpinfo:
Registered Stream Socket Transports tcp, udp
vs on machines where it is working:
Registered Stream Socket Transports tcp, udp, ssl, sslv3, sslv2, tls
But I'm not sure if that's a red herring or not.
My solution for the problem was to uninstall PHP completely and run the php-5.2.13-nts-x86.msi installer and install the OpenSSL library through there.
I had done a manual installation of the OpenSSL library rather than using the Windows installer.
I now do have the following in phpinfo:
Registered PHP Streams php, file, data, http, ftp, compress.zlib, https, ftps
Registered Stream Socket Transports tcp, udp, ssl, sslv3, sslv2, tls
As far as I can tell even according to the openssl installation documentation there shouldn't be a requirement to have to install using the installer. On other machines I haven't had this problem. Altering the 'Registered Stream Socket Transports' to include ssl should only require installing the open_ssl library and adding a line to the php.ini file e.g. this answer.
Related
My client gave me a login to their ftp and I uploaded a code. Unfortunatelly when I try running a website I get PHP Parse error no matter what it is there (as if PHP would not be functioning properly).
Examples:
index.php
<?php
echo 'test';
gives me an error:
PHP Parse error: syntax error, unexpected ''test'' (T_CONSTANT_ENCAPSED_STRING)
What if I try php functions?
<?php
phpinfo();
gives me an error:
PHP Parse error: syntax error, unexpected 'phpinfo' (T_STRING)
Does anyone have any clue what is going on?
P.S. Client does not want to me to give login credentials to server since "there are a lot of important data"...
UPDATE
Using <? or <?= instead of <?php did the job. But I would love to have <?php working instead since project contains of hundreds of php files opening with <?php.
phpinfo() information:
PHP Version 5.6.31
System Linux cp60.webserver.pt 2.6.32-673.26.1.lve1.4.29.el6.x86_64 #1
SMP Tue Jun 20 13:27:00 EDT 2017 x86_64 Build Date Jul 17 2017 09:37:47
Server API CGI/FastCGI
Virtual Directory Support disabled
Configuration File (php.ini) Path /opt/alt/php56/etc
Loaded Configuration File /opt/alt/php56/etc/php.ini
Scan this dir for additional .ini files /opt/alt/php56/link/conf
Additional .ini files parsed /opt/alt/php56/link/conf/alt_php.ini
PHP API 20131106
PHP Extension 20131226
Zend Extension 220131226
Zend Extension Build API220131226,NTS
PHP Extension Build API20131226,NTS
Debug Build no
Thread Safety disabled
Zend Signal Handling disabled
Zend Memory Manager enabled
Zend Multibyte Support provided by mbstring
IPv6 Support enabled
DTrace Support disabled
Registered PHP Streams https, ftps, compress.zlib, compress.bzip2, php, file, glob, data, http, ftp, phar, zip
Registered Stream Socket Transports tcp,
udp, unix, udg, ssl, sslv3, tls, tlsv1.0, tlsv1.1, tlsv1.2
Registered Stream Filters zlib., bzip2., convert.iconv., string.rot13,
string.toupper, string.tolower, string.strip_tags, convert.,
consumed, dechunk, mcrypt., mdecrypt.
In the end it was encoding issue by FileZilla... I change Transfer option to "Binary" and now it works as usual.
I've read a lot of issues with php file encoding while transfering using ftp and most of them have symptoms as mine (php opening tag not working). I will leave the question so someone with the same problem would find a solution.
I am trying to get rid of this error when sending notifications using the ssl protocol in php code:
"Failed to connect: 1976434032 Unable to find the socket transport
\"ssl\" - did you forget to enable it when you configured PHP?"
1: The system is SUSE Linux Enterprise Server 11 SP3.
2: When doing this command rpm -qa | grep ssl, I get:
- openssl-certs-1.97-0.3.1
- openssl-0.9.8j-0.80.1
- libopenssl0_9_8-0.9.8j-0.80.1
- libopenssl0_9_8-32bit-0.9.8j-0.80.1
3: Inside the php.ini file, this line has been uncommented and apache has been restarted:
- extension=php_openssl.dll
4: Looking at phpinfo, i have these settings:
- Registered PHP Streams => php, file, glob, data, http, ftp
- Registered Stream Socket Transports => tcp, udp, unix, udg
- Registered Stream Filters => string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk, convert.iconv.*
THIS SECTION DOES NOT APPEAR IN THE FILE:
- openssl
- OpenSSL support => enabled
- OpenSSL Library Version => OpenSSL 1.0.1e-fips 11 Feb 2013
- OpenSSL Header Version => OpenSSL 1.0.1e-fips 11 Feb 2013
According to these informations, it looks like openssl is not installed or configured properly. But I have no clue how to fix the issue.
What should i do to enable openssl in php to get rid of this message:
"Failed to connect: 1976434032 Unable to find the socket transport
\"ssl\" - did you forget to enable it when you configured PHP?"
Does anyone could help me?
First time asking a question here, please be gentle :-)
I'm writing a PHP command-line script on a Synology box to fetch files via ftps, and start out with this bit:
$ftp = ftp_ssl_connect("ftp.example.com");
When run from the command line, I get
Fatal error: Call to undefined function ftp_ssl_connect() in ...
phpinfo() tells me:
...
Registered PHP Streams => php, file, glob, data, http, ftp, https, ftps, zip, compress.zlib, compress.bzip2
Registered Stream Socket Transports => tcp, udp, unix, udg, ssl, sslv3, sslv2, tls
...
openssl
OpenSSL support => enabled
OpenSSL Library Version => OpenSSL 1.0.1p-fips 9 Jul 2015
OpenSSL Header Version => OpenSSL 1.0.1p-fips 9 Jul 2015
and /etc/php/conf.d/extensions.ini contains extension = openssl.so (without an initial ;)
It seems to me that all the prerequisites for ftp_ssl_connect() are in place.
fwiw:
$ uname -a
Linux DiskStation01 2.6.32.12 #5644 Wed Oct 28 12:36:45 CST 2015 armv5tel GNU/Linux synology_88f6282_213
What would be the next place to look?
Type php -m to see the compiled in modules, as PHP does not ship the FTP extension by default if not on Windows. Calling phpinfo() should also show the compiler switches used, and if they include --enable-ftp.
The curious thing is I just tried this on an RS812 of mine, and it shows both the FTP and OpenSSL moodules as included, and it works fine:
nas-name> php -r "ftp_ssl_connect('test');"
PHP Warning: ftp_ssl_connect(): php_network_getaddresses: gethostbyname failed
in Command line code on line 1
This indicates the ftp_ssl_connect is working but not being able to parse the supplied host name. I have no idea why yours would be different unless you compiled PHP yourself.
As mentioned in Niels solution the ftp-Module is missing in the default installation. I needed the module in the CLI version of PHP, but it was unavailable on all four of my Synology Devices (DS 412+, DS 410, RS812+ and RS814+).
Enabling the module in the Web Station settings did not help, but there is a solution for the CLI version in a Synology Forum Entry:
make sure that the ftp extension is selected within php settings of Web Station.
then edit /etc/php/php.ini to include a line like this:- extension = /volume1/#appstore/PHP5.6/usr/local/lib/php56/modules/ftp.so
that's it. No restarting of Web Station or the NAS is required, as php loads itself from the commandline each time a call is made to php.
I upgraded from an older lubutu release to 14, now running PHP 5.5 and phpMyAdmin 4.0.10deb1, I regularly move small MySQL database exports between hosts (700KB gzip, around 7-10MB decompressed SQL).
You attempted to load file with unsupported compression (application/gzip). Either support for it is not implemented or disabled by your configuration.
This was all working swimmingly on the older PHP setup, I'm not sure if it's a mime type thing or a configuration issue.
I can provide detailed phpinfo() dumps, but zlip is there, phar, etc:
Registered PHP Streams https, ftps, compress.zlib, compress.bzip2, php, file, glob, data, http, ftp, phar, zip
Registered Stream Socket Transports tcp, udp, unix, udg, ssl, sslv3, tls
Registered Stream Filters zlib.*, bzip2.*, convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk
The gzipped sql files aren't corrupt, they decompress and load manually without issue. If there's some configuration setting you can suggest I'll try that out
i had the same problem under different configuration: Ubuntu 16.04 + PHP 7.0 + VirtualMin.
The zip library for php7.0 was simply not installed, so this fixed the problem:
apt-get install php7.0-zip
Edit: this works for php 7.0, the command must suit your php version (7.x)
Put the fix from here http://piwigo.org/forum/viewtopic.php?pid=151458
if (extension_loaded('zlib') && !function_exists('gzopen') && function_exists('gzopen64'))
{
function gzopen($filename, $mode, $use_include_path = 0) {
return gzopen64($filename, $mode, $use_include_path);
}
}
in your /etc/phpmyadmin/config.inc.php. Then it will survive an apt-get upgrade.
Here's an alternative scenario for you.
Downloaded an SQL file from phpmyadmin to local laptop.
Before uploading to new server , I compressed locally form within finder. ( this is the mistake ) as this adds __MACOS folder to the compressed file. myfile.sql.zip
Generates the same error message.
phpMyAdmin doesn't load database import file with unsupported
compression (application/gzip)
To stop that from happening, just gzip the file from the command line so you have..
gzip myfile.sql
myfile.sql.gz
and upload that.
Thanks for all the comments, looking around some of the links I the issue is the Debian/Ubuntu choice of zlib providing the php function gzopen64 rather than the expected gzopen, solution outlined here: http://kb.parallels.com/en/116645
/usr/share/phpmyadmin/import.php provides the following, changing gzopen to gzopen64 fixes the issue
case 'application/gzip':
if ($cfg['GZipDump'] && #function_exists('gzopen')) {
$import_handle = #gzopen($import_file, 'r');
} else {
$message = PMA_Message::error(
__('You attempted to load file with unsupported compression (%s). Either support for it is not implemented or disabled by your configuration.')
);
$message->addParam($compression);
PMA_stopImport($message);
}
break;
On CentOS 8
yum install php-pecl-zip
Should fix it.
you probably have to configure you apache server:
see this link for more informations : http://httpd.apache.org/docs/2.2/mod/mod_deflate.html
Install the 7zip software and zip the data file in gz format and import it.
Your problem will be solved
I'm getting:
Warning: ldap_start_tls()
[function.ldap-start-tls]: Unable to
start TLS: Connect error in
/var/www/X.php on line Y
/etc/ldap/ldap.conf:
TLS_CACERT /etc/ssl/certs/ca.crt
ca.crt is the CA which signed the LDAP server certificate. The certificate on the LDAP server is expired and I can't change it.
You can ignore the validity in windows by issuing
putenv('LDAPTLS_REQCERT=never');
in your php code. In *nix you need to edit your /etc/ldap.conf to contain
TLS_REQCERT never
Another thing to be aware of is that it requires version 3 (version 2 is php default):
//$hostnameSSL example would be "ldaps://just.example.com:636" , just make sure it has ldaps://
$con = ldap_connect($hostnameSSL);
ldap_set_option($con, LDAP_OPT_PROTOCOL_VERSION, 3);
To get a better idea of what's going on, you can enable debug logging by:
ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7);
This can be done before the ldap_connect takes place.
The specific scenario presented in the question--with an expired certificate that can't be changed--does appear to require disabling certificate validation on the LDAP client.
However, I suspect a lot of people, like me, reach this page for other root causes of receiving opaque LDAP TLS errors, where disabling validation of TLS certificates is not an appropriate answer.
In my case--using the LDAP Authentication extension for Mediawiki on an Ubuntu 18.04 LTS server, and authenticating against Active Directory on a Windows Server 2012 server--authentication stopped working in January/February 2020. The server certificate and the CA certificate were still both valid, and openssl s_client -verify 2 -connect <AD server>:636 from the Mediawiki server passed just fine.
Eventually I noticed that the signature algorithm in the SSL certificate served by AD/LDAP was SHA1, which I remembered recently suffered from the first known chosen-prefix collision exploit. This led me to investigate the changelog for packages that had recently been updated on the system, which turned up "Mark SHA1 as insecure for certificate signing" in the gnutls28 changelog circa January 8th, 2020. (The chain of dependencies from the php-ldap package in Ubuntu 18.04 goes to php7.2-ldap -> libldap-2.4-2 -> libgnutls30, whose source package is gnutls28.)
I followed some instructions to update the Windows CA to use SHA256 and then selectively followed instructions to renew the AD/LDAP cert, installed the new CA cert on my Mediawiki server, and the problem was solved! Briefly, these steps included:
In an Admin PowerShell on the AD server, run certutil -setreg ca\csp\CNGHashAlgorithm SHA256
In the Certification Authority MMC, right click on the CA -> All Tasks -> Renew CA Certificate
In a blank MMC, add snap-in for Certificates; select Local Computer
Under Personal -> Certificates, find the current entry used by LDAPS (Kerberos Authentication template type) -> All Tasks -> Advanced Options -> Renew This Certificate with the Same Key
In the same window, open the new CA certificate -> Details -> Copy to file -> no private key -> base64-encoded X.509
Copy the resulting file to /usr/share/ca-certificates/ on the Mediawiki server, then run sudo dpkg-reconfigure ca-certificates and select the new CA cert for inclusion.
P.S. For SEO purposes, depending on the mode I was using, error messages included:
ldap_start_tls(): Unable to start TLS: Connect error in /var/www/mediawiki/extensions/LdapAuthentication/LdapAuthenticationPlugin.php in the HTTP error log
ldap_start_tls(): Unable to start TLS: Can't contact LDAP server in [...]
Failed to start TLS. in the Mediawiki debug log (when using wgLDAPEncryptionType = ssl, i.e. encrypted LDAP port, 636)
Failed to bind as CN=foobar,CN=Users,DC=myOrgName,DC=local in the Mediwiki debug log (when using wgLDAPEncryptionType = tls, i.e. STARTTLS on the unencrypted LDAP port, 389)
My solution/workaround is to use
/etc/ldap/ldap.conf:
#TLS_CACERT /etc/ssl/certs/ca.crt
TLS_REQCERT never
If you have any better idea, please post another answer.
The path for ldap.conf in Windows is fixed:
c:\openldap\sysconf\ldap.conf
A restart of the web server may be required to apply changes.
In debian based systems:
Install the package: ldap-utils and in the file
/etc/ldap/ldap.conf, edit the line:
TLS_CACERT /etc/ldap/cacerts/cacert.asc
Create the directory /etc/ldap/cacerts and copy the cacert to
/etc/ldap/cacerts/cacert.asc
Restart apache.
In redhat based systems:
Install the package: openldap-clients and in the file
/etc/openldap/ldap.conf edit the line:
TLS_CACERT /etc/openldap/cacerts/cacert.asc
Create the directory /etc/openldap/cacerts and copy the cacert to
/etc/openldap/cacerts/cacert.asc
Restart httpd
I was able to get this working properly with openldap on Amazon Linux (Elastic Beanstalk PHP 7.0) with MacOS Server 5 LDAP, with TLS set to demand.
in /etc/openldap/ldap.conf:
TLS_REQCERT demand
TLS_CACERT /etc/openldap/certs/yourcacert.pem
(note that if you are not using openldap, the path will be /etc/ldap/certs/yourcacert.pem). This setup did not work until I placed the certificate inside the certs folder; it did not work from any other path.
The certificate to be placed in that path is NOT the TLS certificate of the server. It is the CA (Certificate Authority) certificate of the authority whom issued the server/domain specific TLS certificate. Only the CA certificate placed in that path will allow TLS to work before attempting an LDAP bind in php. Get the CA certificate from your server or download it from the authority's site, they are freely available.
To test if LDAP bind is even working without TLS, set TLS_REQCERT never temporarily (may need to comment # out TLS_CACERT). If you get "Can't connect to LDAP" it is not a TLS error; it simply cannot connect to the server and you likely need to open port 389 (not 636 for TLS).
Remember to restart your Apache server every time you make a change to the config file or certificate.
Some additional help for others, the certificate solution here solved my ldapsearch command line issue, but still PHP complained **Can't contact LDAP server**
Turned out to be SELinux on RHEL7 ( CentOS7 ) blocks HTTPD from using LDAP ports 389 and 636 by default, you can unblock with:
setsebool -P httpd_can_network_connect 1
Check your SELinux audit log file for things being blocked.