Please stop reporting the same issue over and over again.  Thanks.

cmb@php.net -> clearly you didnt read this bug report! It's different from ANY of the other bugs I reported!

Now, the CURL simply does not work. It does not matter if you will open a database connection previsouly or if you create a previous connection with SSL. No!

This BUG HAPPENS SIMPLY USING CURL ONCE!

Sorry!

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.

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"
  }
}

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.

One more note: using "echo curl_error($curl); " shows a blank string! So curl is not showing any error.

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?

nikic@php.net I just woke up right now and went to try your code and suddenly this bug went away. I didnt make ANY update yesterday. I didnt do "yum update" and for some reason CURL came back to work!

Then I tried adding the line of code - mysqli_connect("localhost","root","password") - above the CURL and then it crashed  again. Which means that the bug that I reported a few days back came back to happen again.

So now, CURL only does not work when opening the mysqli connection.

Nikik I tried that 2 line of codes you asked me and the output follows below:

CODE:

<?php

$conn = mysqli_connect("localhost","root","password");

$curl = curl_init();

$opts = array();

$opts[CURLOPT_URL] = "https://www.sitepor500.com.br";

$opts[CURLOPT_RETURNTRANSFER] = true;

curl_setopt_array($curl,$opts);


var_dump(curl_exec($curl));

var_dump(curl_errno($curl))

?>

OUTPUT

bool(false)
int(77)

I investigated, and 77 means -> CURLE_SSL_CACERT_BADFILE.

ALSO one even strange thing, if I replace 

$conn = mysqli_connect("localhost","root","password"); 

with just

mysqli_connect("localhost","root","password");

The bug goes away and everything works! 

Hope this helps and if you want me to execute any other code, I am here to help!

One more thing, I tried using the CART file from https://curl.haxx.se/ca/cacert.pem and it also does show the same exactly error, so I am pretty cure there is no problem with cacert or certificate bundle.

If your original code, the one where you do *not* do anything over an SSL connection before using cURL, is no longer causing any problems then we're back to this being a duplicate of the other report.

requinix@php.net you are right. This bug now only happens when opening a mysqli connection previously to using CURL with HTTPS. I have no idea how this bug "fixed" itself cause I could easily reproduce it on a fresh install of centos + lamp on Linode (cloud server company) and I didnt any "yum update" after the install. Have no idea how it got fixed HOWEVER the bug still happens when opening a mysqli connection previsouly to using CURL with HTTPS.

This is pretty weird, because your curl is linked against NSS (first time I'm seeing that particular combination...), while mysql will use OpenSSL. Assuming it's using mysqlnd.

I don't really have a good idea on how to debug this (short of making this reproducible in something like Docker) ... possibly running PHP under "strace" and taking a look at the log would give some insight into where the failure originates.

To clarify, running under strace should be as simple as "strace php script.php".

(Copying this comment from bug #78845, I mixed up the tabs.)

Sorry I dont know how to use strace :( But isnt anyone of you able to reproduce this on a clean cloud server install with LAMP?