topic SSL Timeout Connecting to Sandbox in Integration and Testing

SSL Timeout Connecting to Sandbox

gmarlett — Tue, 03 Jun 2014 19:01:53 GMT

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

Re: Sandbox down?

Lilith — Tue, 03 Jun 2014 18:09:58 GMT

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?

Re: Sandbox down?

gmarlett — Tue, 03 Jun 2014 18:20:03 GMT

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] =>
)

Re: Sandbox down?

Lilith — Tue, 03 Jun 2014 18:59:16 GMT

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.

Re: Sandbox down?

peter — Tue, 03 Jun 2014 18:27:53 GMT

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-could-not-be-verified/td-p/41382

Re: Sandbox down?

gmarlett — Tue, 03 Jun 2014 18:30:34 GMT

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

Re: Sandbox down?

Lilith — Tue, 03 Jun 2014 18:46:58 GMT

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

Re: Sandbox down?

Lilith — Tue, 03 Jun 2014 18:48:58 GMT

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?

Re: Sandbox down?

bbot — Tue, 03 Jun 2014 18:58:33 GMT

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.

Re: Sandbox down?

Lilith — Tue, 03 Jun 2014 19:02:46 GMT

Are you using OpenSSL? If so, which version?

Re: Sandbox down?

peter — Tue, 03 Jun 2014 19:08:05 GMT

This is what our VPS runs.

Server Type: Apache/2.2.27 (Unix) mod_ssl/2.2.27 OpenSSL/1.0.1e-fips mod_bwlimited/1.4

Re: Sandbox down?

bbot — Tue, 03 Jun 2014 19:28:00 GMT

It's a vagrant box that says:

$ openssl version

OpenSSL 1.0.1f 6 Jan 2014

PHP reports the same version of ssl. It's as far upgraded as a dist-upgrade and an apt-get update; apt-get upgrade will do on my vagrant VM.

Re: Sandbox down?

Lilith — Tue, 03 Jun 2014 19:33:07 GMT

Thanks. We suspect at this point that it may be specific to OpenSSL and the SSL versions enabled in it.

Can you force OpenSSL to use SSL v3 or TLS 1.0?

Re: Sandbox down?

bbot — Tue, 03 Jun 2014 19:38:44 GMT

I'm honestly not sure how to go about doing that... any tips for an ubuntu/debian environment running apache/php?

Re: Sandbox down?

gmarlett — Tue, 03 Jun 2014 19:46:31 GMT

Is this issue going to impact the live Authorize.net at some point? Our production server is using OpenSSL 1.0.1e-fips

Re: SSL Timeout Connecting to Sandbox

lethjakman — Tue, 03 Jun 2014 19:53:01 GMT

Hello, I'm having the same issue as mentioned in this post. I contacted the support technicians and was directed here. I'd like to point out that I have three people here in this office, myself included, all running "OpenSSL 0.9.8y 5 Feb 2013". It worked just fine when I left, then this morning when everyone booted up their machines my two fellow workers could not send requests, however I could. I'm the only one who hasn't turned off their machine since then, and I can still send requests without the SSL error. No clue what's going on, any advise would be helpful. Seems to me like there's some sort of weird caching going on or something.

Re: SSL Timeout Connecting to Sandbox

gmarlett — Tue, 03 Jun 2014 20:10:14 GMT

My co-developer upgraded his WAMP to OpenSSL/1.0.1g and the issue does not occur.

Re: SSL Timeout Connecting to Sandbox

bbot — Tue, 03 Jun 2014 20:38:40 GMT

I wish I could upgrade...

according to http://askubuntu.com/questions/449184/how-to-upgrade-openssl-1-0-1f-on-ubuntu-server-14-04 it looks like the 1.0.1f included in ubuntu 14.04 has been patched to fix the heartbleed bug, but still doesn't work with ADN

Re: SSL Timeout Connecting to Sandbox

gmarlett — Tue, 03 Jun 2014 20:46:20 GMT

I'm about to try to upgrade our production server to it (CentOS). I'll let you know if I'm able to.

Re: SSL Timeout Connecting to Sandbox

lethjakman — Tue, 03 Jun 2014 20:48:20 GMT

OpenSSL/1.0.1g doesn't make any difference on OSX. Same exact error.