cancel
Showing results for 
Search instead for 
Did you mean: 

SSL Timeout Connecting to Sandbox

The CIM API is timing out for us.  Is anyone else having this issue or is it just us?

gmarlett
Contributor
74 REPLIES 74

The Sandbox environment is not down--if you try to load https://test.authorize.net/gateway/transact.dll in a web browser you'll get Response Reason Code 13, which is expected behavior since there's no x_login info being passed.

If you try it with the CIM API URL in Sandbox (https://apitest.authorize.net/xml/v1/request.api) you'll get similar results--a successful connection with an error from us due to a lack of actual content in the connection.

But can you provide us with more details, such as whether you're seeing SSL errors when trying to connect to Sandbox?

--
"Move fast and break things," out. "Move carefully and fix what you break," in.
Lilith
Administrator Administrator
Administrator

It was working for us yesterday (and we didn't change any code).

 

After about a minute or two it times out and returns an empty response.  The same code is working on our production site with the live authorize.net

 

AuthorizeNet\Service\Cim\Response Object
(
[xml] =>
[response] =>
)

I'm asking about SSL errors because we added new ciphers to Sandbox, and it's possible that affected servers are having issues using these ciphers.

These are the ciphers we added, so please ensure your solution properly supports these:

  • TLS_RSA_WITH_RC4_128_MD5 (0x4)
  • TLS_RSA_WITH_RC4_128_SHA (0x5)
  • TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
  • TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
  • TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 1024 bits (p: 128, g: 1, Ys: 128)
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits (p: 128, g: 1, Ys: 128)
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits (p: 128, g: 1, Ys: 128)

EDIT: There are a few ciphers we will be removing because they are weak ciphers, but all the weak ciphers were part of the new update. I've updated this post to reflect the ciphers we previously supported, plus the strong ciphers we will be keeping and supporting moving forward.

--
"Move fast and break things," out. "Move carefully and fix what you break," in.

Are these new ciphers a reason I may be getting an error "The SSL certificate for the host could not be verified."

 

From my question http://community.developer.authorize.net/t5/Integration-and-Testing/SSL-certificate-for-the-host-cou...

I found that there is a response, at the bottom there is this:

 

[error_message] => Error connecting to AuthorizeNet

 

I am unsure what we would need to do to get everything working with the new ciphers.  We two developers with local development accounts and one VPS development server that all have this issue.  The developers are on WAMPs and the VPS is Linux...

 

Here is the full response:

 

[approved] =>
[declined] =>
[error] => 1
[held] =>
[response_code] =>
[response_subcode] =>
[response_reason_code] =>
[response_reason_text] =>
[authorization_code] =>
[avs_response] =>
[transaction_id] =>
[invoice_number] =>
[description] =>
[amount] =>
[method] =>
[transaction_type] =>
[customer_id] =>
[first_name] =>
[last_name] =>
[company] =>
[address] =>
[city] =>
[state] =>
[zip_code] =>
[country] =>
[phone] =>
[fax] =>
[email_address] =>
[ship_to_first_name] =>
[ship_to_last_name] =>
[ship_to_company] =>
[ship_to_address] =>
[ship_to_city] =>
[ship_to_state] =>
[ship_to_zip_code] =>
[ship_to_country] =>
[tax] =>
[duty] =>
[freight] =>
[tax_exempt] =>
[purchase_order_number] =>
[md5_hash] =>
[card_code_response] =>
[cavv_response] =>
[account_number] =>
[card_type] =>
[split_tender_id] =>
[requested_amount] =>
[balance_on_card] =>
[response] =>
[error_message] => Error connecting to AuthorizeNet

You may need to discuss this with your webmaster. This is typically at the server level, not the code level.

--
"Move fast and break things," out. "Move carefully and fix what you break," in.

Peter, that is a possibility. Are you using OpenSSL? If so, which version? We're researching this and knowing the OpenSSL version number would help.

If you aren't using OpenSSL, which version of IIS are you using?

--
"Move fast and break things," out. "Move carefully and fix what you break," in.

I'm having the same issue:  manually visiting https://apitest.authorize.net/xml/v1/request.api works just fine, but submitting both GetCustomerProfile and CreateCustomerProfile requests are timing out (via curl through php api).  No code has changed since yesterday, and the code did work yesterday.  I'm glad I'm not the only one.

 

Fustrating, it's killed about 4 hours of development time today because I thought it may be our fault, somehow.

Are you using OpenSSL? If so, which version?

--
"Move fast and break things," out. "Move carefully and fix what you break," in.
Lilith
Administrator Administrator
Administrator