2

I am getting a seemingly sporadic error from Authorize.net calls. This is the error that is logged.

     [result] => Array
    (
        [response_code] => -1
        [response_reason_code] => 0
        [response_reason_text] => Unable to read response, or response is empty
    )

The error started after several months of trouble free operation (~5 orders/day). The customers will get the error and most will just try again. It is usually successful after 2-3 tries. Some customers are successful on their first. This issue has been present for a week now, but it is not consistent. We have had several day long stretches without the error.

I am logging the request and response timestamps and it does not hit the 30 second timeout set in the Magento Authorize.net code. Is there a timeout on the Authorize.net side?

We are on a two server cluster, The error is only happening on one of the servers.

Any clues? I have exhausted my knowledge on this.

Magento Community Edition 1.8.0 Authorize.net (Not Direct Post Method)

2

Something something DNS Lookup was failing. Our server support changed something, I don't know what, but it appears to have fixed it.

This was not a Magento application issue, it was a server issue.

  • what host were you with, we're experiencing the same issue on MageMojo – Haim Feb 3 '16 at 16:29
  • Can you ask your server support what they fixed? – Rishi May 24 '18 at 0:01
1

It also could be curl issue over ssl: Problem with the SSL CA cert (path? access rights?). In this case restarting apache web server also can be right solution. https://stackoverflow.com/questions/7179216/php-problem-with-the-ssl-ca-cert-path-access-rights

1

Our issue had to do with the version of libcurl (7.19.7) packaged with CentOS 6.6. To be clear, this was just an issue on Authorize.net's sandbox. All of a sudden our test orders to Authorize were failing with the OP's error above.

CURL SSL issues can be fun to debug; to determine the issue, we temporarily added the following code to lib/Varien/Http/Adapter/Curl.php

public function read()
{
    /** Temporarily Added  to Debug */
    curl_setopt($this->_getResource(), CURLINFO_HEADER_OUT, false);
    curl_setopt($this->_getResource(), CURLOPT_VERBOSE, true);
    /** End Temporary Debug $response */

     ...
}

Assuming that PHP logging is enabled, this provides verbose information regarding the transaction. In our case:

stderr: "* About to connect() to test.authorize.net port 443 (#0)"
stderr: "*   Trying 184.31.194.197... "
stderr: "* "
stderr: "connected"
stderr: "* "
stderr: "Connected to test.authorize.net (184.31.194.197) port 443 (#0)"
stderr: "* "
stderr: "Initializing NSS with certpath: sql:/etc/pki/nssdb"
stderr: "* "
stderr: "  CAfile: /etc/pki/tls/certs/ca-bundle.crt"
stderr: "  CApath: none"
stderr: "* "
stderr: "NSS error -5961"
stderr: "* "
stderr: "Closing connection #0"
stderr: "* "
stderr: "SSL connect error"

As it turns out, the NSS error lead us to our libcurl library which was out of date and was defaulting to TLS Protocol v 1.1; To verify, I temporarily added curl_setopt($this->_getResource(), CURLOPT_SSLVERSION, 6); to the read method above. Indeed, this allowed the transaction to proceed.

Solution

I updated libcurl to the current version to utilize TLS 1.2 by default. This will definitely vary by Linux flavor so please do not take verbatim but as an example.

For example:

wget http://curl.haxx.se/download/curl-7.42.1.tar.bz2
tar -xvjf curl-7.42.1.tar.bz2
cd curl-7.42.1
./configure --prefix=/usr
make; make install
ldconfig -v

curl --version to verify that libcurl was updated.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.