Bug #78891 [Fbk]: Bug with CURL completely stopped working

Edit report at https://bugs.php.net/bug.php?id=78891&edit=1 ID: 78891 Updated by: nikic@php.net Reported by: gilperon at gmail dot com Summary: Bug with CURL completely stopped working Status: Feedback Type: Bug Package: Unknown/Other Function Operating System: all PHP Version: 7.2.25 Block user comment: N Private report: N New Comment: It's pretty weird that curl_error() doesn't report anything here. Just to double check, if you replace the "echo curl_exec($curl)" with "var_dump(curl_exec($curl))", do you get "bool(false)" or "string(0)"? And afterwards, does "var_dump(curl_errno($curl))" give "int(0)" as well? Previous Comments: ------------------------------------------------------------------------ [2019-11-30 17:14:40] gilperon at gmail dot com One more note: using "echo curl_error($curl); " shows a blank string! So curl is not showing any error. ------------------------------------------------------------------------ [2019-11-30 17:10:48] gilperon at gmail dot com I just forgot to say that when I open my Centos terminal and execute the command below, everything works fine: curl https://www.sitepor500.com.br So, using curl directly from the terminal, works fine. Only using it with PHP is that gets buggy. ------------------------------------------------------------------------ [2019-11-30 17:06:48] gilperon at gmail dot com nikic@php.net thanks for your attention. I can easily reproduce this bug installing LAMP on a CENTOS 7 new server on Linode. Just fire a cloud server, install lamp with PHP using 7.2.25 and the bug happens. Using file_get_contents the bug does not happen. Only with CURL. Also, the CURL code that I provided you, does not return any error, just an empty string when the requested domain contains HTTPS protocol. There is no error reported at error_log of Apache! Regarding the version of the libcurl I executed the code "var_dump( curl_version() );" and I got this: array(9) { ["version_number"]=> int(466176) ["age"]=> int(3) ["features"]=> int(558781) ["ssl_version_number"]=> int(0) ["version"]=> string(6) "7.29.0" ["host"]=> string(23) "x86_64-redhat-linux-gnu" ["ssl_version"]=> string(8) "NSS/3.36" ["libz_version"]=> string(5) "1.2.7" ["protocols"]=> array(20) { [0]=> string(4) "dict" [1]=> string(4) "file" [2]=> string(3) "ftp" [3]=> string(4) "ftps" [4]=> string(6) "gopher" [5]=> string(4) "http" [6]=> string(5) "https" [7]=> string(4) "imap" [8]=> string(5) "imaps" [9]=> string(4) "ldap" [10]=> string(5) "ldaps" [11]=> string(4) "pop3" [12]=> string(5) "pop3s" [13]=> string(4) "rtsp" [14]=> string(3) "scp" [15]=> string(4) "sftp" [16]=> string(4) "smtp" [17]=> string(5) "smtps" [18]=> string(6) "telnet" [19]=> string(4) "tftp" } } ------------------------------------------------------------------------ [2019-11-30 13:09:13] nikic@php.net This issue is almost certainly not on the PHP side, but either due to a libcurl update (maybe you pulled one in together with a PHP update?) or a misconfiguration of the certificate store (most likely). The fact that this happens with just curl, that there have been no recent code changes (in PHP) in this area, and the issue is not reproducible by other people (I just tried your code, works just fine) is a pretty strong indication of that. To say more here, at the very least it would be important to know a) what error curl reports and b) what libcurl version you're using and whether it was updated recently. ------------------------------------------------------------------------ [2019-11-30 12:30:55] cmb@php.net Sorry! ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=78891 -- Edit this bug report at https://bugs.php.net/bug.php?id=78891&edit=1