Production Certificate Upgrades begin May 26, 2015

[RichardH]

Authorize.Net will upgrade and replace Production certificates for API services starting May 26, 2015. Technical details are provided for solutions connecting to Authorize.Net APIs that may need updates.

To see the full announcement, please see this blog post.

[Lilith]

To clarify @RichardH's reply--the network infrastructure change to dynamic IPs will be applied to our APIs in August.

And to address what I believe to be @flinacio's concern: Our general recommendation is to follow PCI DSS 1.3.1 and 1.3.5 to set up a DMZ between your production environment and the general Internet, whitelist all inbound and outbound traffic between the production environment and the DMZ, and allow the DMZ to initiate outbound connections to any IP address. Inbound connections to the DMZ can be blocked entirely, unless you use Relay Response or Silent Post. Both data streams will continue to come from a limited range of IP addresses, which Authorize.Net Merchant Support can provide on request.

If you're concerned about SHA-2, that is already rolling out, and May 26 is the date when secure.authorize.net and api.authorize.net will receive SHA-2 certificates.

[Lilith]

@Msimpson, if your software or server OS is legacy--if it hasn't been upgraded to keep up with general security practices--then it's possible your server may not be able to validate SHA-2 signed certificates. Given SHA-2 has been around for over a decade, legacy software and servers are really the concern here.

If your software or server's firewall is extremely restrictive, in August you may run into difficulties as our upcoming network infrastructure will have dynamic IP addresses on the front end.

Beyond that, it really depends on the particulars of your software and server. You may want to start with a quick code review to see if your software uses its own certificate store, or if it uses your server's store instead, and then check the store to confirm you have the mentioned certificates in place. There is a good chance you may have them already.

You'll also want to check your network setup to make sure your DMZ can connect to any IP address. (It can refuse inbound connections unless you're using Relay Response or Silent Post, and in those cases we can give you IP address ranges so you can configure your firewall to allow those connections.)

[tpeierls]

That's what I needed to know, thank you. (And thanks to whoever responded to my query via the developer support page.)

I gathered from one of the reference pages that the blog post mentioned that any Java version from 1.4.2 on should work, presumably because the cacerts file that comes with the Java distribution started including SHA-2 CA certs at that point. But I wanted to be sure.

[mishenka]

Hello Everyone,

I tried calling support and the case has been opened. But I would like to try to resolve my question here, please. 

Our system is built on .NET framework. It runs on IIS 6.0 with ASP.NET 2.0. The machine is Microsoft Windows Server 2003 R2 Service Pack 2. The program utilizes AIM API mechanism and all transactions are occurring on https://secure.authorize.net/gateway/transact.dll in production. We have 5 active gateway accounts. 

Our IT installed ALL the certs recommended in this (http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Production-Certificate-... blog post. They are installed in the Certificate Store for Local Computer.

When I repoint the system to a sandbox account (which I have registered and use the corresponding API Login ID and Transaction Key) https://test.authorize.net/gateway/transact.dll  - the connection with your servers cannot even be established. This is the error I get: "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel."

Please, help to troubleshoot hte issue. If my understanding is correct - there is nothing that I need nor can change in the code. As I said above it is a .NET (c#) code that runs in the context of IIS (ASP.NET) that simply utilizes the Authnet API. All works now. The API is not changed, correct? Only the way the SSL is signed. As soon as I change the endpoint to direct my transaction request to the sandbox url - the system stops working. Well.. not the entire system, only the payment functionality, of course.

Please, I truly would appreciate if the dev team can help me here. Any advice or suggestion is very much appreciated.

Michael Shapiro

[RaynorC1emen7]

can you open an IE browser windows on that 2003 server the sandbox url https://test.authorize.net/gateway/transact.dll

Just try it on one of our old 2003 server and it getting error going to the url too. Work fine on newer server. It the server windows update up to date?

[mishenka]

Trying to open the https://test.authorize.net/gateway/transact.dll in IE was, of course, the first thing I tried. You are correct - IE cannot go to this URL. I will have to check on what the latest OS update we have on that server.

Interesting fact - going to https://test.authorize.net/gateway/transact.dll in Firefox - works. But the https portion of the url is displayed in different color compared to if I use the production URL. 

. 

[RaynorC1emen7]

I can't touch that server so I don't know if taking all windows security updates would fixes it, but it probably would.

The fail one is 2003 with IE 6.

Found another 2003 with more up to date updates include IE 8, when I set to accept TLS 1.0 on the IE settings it go thru the test.authorize.net site.

IIS/IE are intergrated to the OS. Firefox probably use it own SSL engine.

[rperntice84]

Can someone point me to a script I can use to test my environment? I Took over this system and we dont have any admin team I can go to to verify everything will work with the change over. We use Auth AIM within Zen-Cart currently and we do have an SHA2 signed SSL for our site but not sure if the server will support SHA2 when communicating with Auth.

[rperntice84]

I went to the sandbox site, and setup a test script that I downloaded off of developer.authorize.net to test out the sandbox. If i am getting a "Your transaction was approved" via a dummy/test CC using https://test.authorize.net/gateway/transact.dll as my post_url within my server, then my e-com site is compatible with the SHA-2 certificates correct?

I used the PHP Sample AIM Implemention script.

[OIT-AuthNet]

Hi,

Noiticed an inconsistency with the GeoTrust certificate you posted in:

https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Production-Certificate...

Trust Chain:

Common Name - GeoTrust SSL CA - G4

Issuer - GeoTrust Global CA, GeoTrust Inc

Thumbprint  - de 28 f4 a4 ff e5 b9 2f a3 c5 03 d1 a3 49 a7 f9 96 2a 82 12

As checked, common name doesn't match the thumbprint.

The certificate that matches the thumbprint is  Root 2 - GeoTrust Global CA which can be downloaded from:

https://www.geotrust.com/resources/root_certificates/certificates/GeoTrust_Global_CA.pem

While the GeoTrust SSL CA - G4 (Fingerprint=AC 8F 7C 5B C8 6E F1 89 6F 2D 16 1C 32 A5 7A AB 37 D3 64 DA)

can be downloaded from :

https://knowledge.geotrust.com/library/VERISIGN/ALL_OTHER/Cliff/TU85/GEOTRUST_CAcerts/certs/GeoTrust...

Please confirm which certificate should we really install. Thanks.