cancel
Showing results for 
Search instead for 
Did you mean: 

Connection Failure

Anybody else encountering this today? lost 15 transactions already!

svalues
Member
7 REPLIES 7

On a developer account or production account? What URL are you connecting to?

TJPride
Expert

From my staging server connecting to the sandbox server for AIM integration testing I am seeing the following from one staging server, but not from another.  Attempting to connect in a browser on the machine with failures I am seeing similar issues.  Is there a root certificate issue?

 

curl -v https://test.authorize.net/
* About to connect() to test.authorize.net port 443 (#0)
* Trying 64.94.118.151... connected
* Connected to test.authorize.net (64.94.118.151) port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to test.authorize.net:443 
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to test.authorize.net:443

 


Could be that one of your staging servers is using SSLv2 and another SSLv3 and the destination server doesn't support v3. What's the connection log say for the ones that are working?

Server with successful connections has this result for curl

 

curl -v https://test.authorize.net/
* About to connect() to test.authorize.net port 443 (#0)
* Trying 64.94.118.151... connected
* Connected to test.authorize.net (64.94.118.151) port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-MD5
* Server certificate:
* subject: C=US; ST=California; L=Mountain View; O=Cybersource Corporation; OU=PlatinumSSL Wildcard; CN=*.authorize.net
* start date: 2010-03-31 17:04:00 GMT
* expire date: 2012-03-30 17:33:57 GMT
* common name: *.authorize.net (matched)
* issuer: C=US; O=Entrust, Inc.; OU=www.entrust.net/rpa is incorporated by reference; OU=(c) 2009 Entrust, Inc.; CN=Entrust Certification Authority - L1C
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
> Host: test.authorize.net
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Length: 320
< Content-Type: text/html
< Content-Location: https://test.authorize.net/index.htm
< Last-Modified: Tue, 28 Sep 2010 17:34:15 GMT
< Accept-Ranges: bytes
< ETag: "57b4205f335fcb1:4a24"
< Server: Microsoft-IIS/6.0
< X-Powered-By: ASP.NET
< Date: Tue, 13 Mar 2012 21:03:25 GMT
<
<html>
<HEAD><TITLE>Authorize.Net</TITLE>
<META NAME="Authorize.Net -- Enabling more businesses to process transactions worldwide">
</HEAD>
<FRAMESET ROWS="100%,*" BORDER=0 FRAMEBORDER=0 FRAMESPACING=0>
<FRAME NAME="top" src="https://sandbox.authorize.net/ui/themes/anet/merch.app" NORESIZE>
</FRAMESET>
* Connection #0 to host test.authorize.net left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
</HTML>

Well, it's the same protocol, and I assume the Authorize.net server is working the same way for both of your servers, so there has to be something different between your two servers. Is the date set correctly on the one that isn't working? Having an incorrect date can cause SSL failure. Or you might not have the certificate authority that Authorize.net is using in your list of approved certificate authorities.

Do you know what certificate authority authorize.net is using?  I'll check on the date/time problem as well

 

 

Entrust, Inc.