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.

[RichardH]

Hello @OIT-AuthNet

The thumbprints are for the chain certificate.  You should install the root certificate identified at the top of the post.

Richard

[rperntice84]

Question for @RichardH I continued to do tests in the sandbox to the test.authorize.net link and had no issues. I dont know how to install root certificates on the server, but given I am not getting any errors, do I need to if its communicating properly on the sandbox?

If they are required, do you have any tips/help on how I install these on CentoOS 5 (I know its an older OS and we plan on upgrading but thats going to take awhile).

UPDATE: I went and updated OpenSSL to update 34, which also updated the ca-bundle and I see all the CA bundles in there are 2018 and later expirations. Entrust and GeoTrust both show in the lists, so I am hoping that means everything I need is there now? If I only see the GeoTrust matching root in there, is that enough?

[CFJSGeek]

I am reading that the new CA root certificate is using EnTrust SHA-2. I'm also reading that https://test.authorize.net/gateway/transact.dll has the new cerficate in place to test against.

However I'm finding this is not the case. If I hit that URL via Chrome I can see it's using "GeoTrust SSL CA - G4" w/ SHA-1, not EnTrust. Using https://www.ssllabs.com/ssltest/analyze.html?d=test.authorize.net I can confirm the same.

What am I not understanding here? In the end I need to have ColdFusion 8.0.1 on Java 1.6.0_45 communicating with auth.net for a 3rd party client.

Right now if I test against https://test.authorize.net/gateway/transact.dll it works. But I'm concerned that reading the document http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Production-Certificate-... that on May 26th we'll be dead in the water.

Please inform me why I am seeing this status on test.authorize.net instead of the expected read from the article? Thanks in advance.

[RichardH]

Hello @CFJSGeek

We previously announced changes to the sandbox in this blog post: http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Authorize-Net-Begins-In...

Let us know if this does not fully answer your question.

Richard

[CFJSGeek]

@RichardH thanks for the link, but I have read that before posting this question. My questions are still effective.

From what I understand the new root cert and encryption should be different than what the sandbox is currently responding with acording to these articles.

If I am misunderstanding something please elaborate. Thanks.

[RichardH]

@CFJSGeek

If you have both the GeoTrust and Entrust root certificates installed, you should be ready.

Richard

[CFJSGeek]

@RichardH I agree that would help. However I need a test environment that would mimic what production sees on the 26th. Otherwise I risk my production environment going down. Suggestions?

[rperntice84]

@CFJSGeek I recommend emailing them to confirm. I have gotten zero help on these forums to date. According to the rep I chatted with via their contact us link, if you are getting a response back from sandbox at all right now, then you are good for the production environment on Tuesday. I only have the GeoTrust installed and all tests have come back clean.

[sramcse]

We hosted our payment server in linux server managed by our vendor.Its run in apache.

When authorize .NET had done security upgrades in sandbox environment.We faced the connection issue,So to make it work we just replaced the cert.pem file inside authorize .net lib/ssl in test environment.cert.pem file i got from mozilla.

Authorize .NET by May 26th security certificate upgrade happens in production, So what exactly we need to do that makes production environment proper.can you tell us that cert.pem file replacement in production environment is sufficient or have to do any other additional things?.Inform us about exact time when security upgrade happens.

API services to use EnTrust’s SHA-256, 2048-bit certificate.So, should root certificate of this contain in cert.pem file?

[phippster]

We did full testing on the sandbox and everything worked just fine.  Today, 5/26 when changes went into production our entire system stopped working.  We had previously installed all 15 different root certficates linked to from the original blog post about the updates.

This example works just fine:

openssl s_client -connect apitest.authorize.net:443

This connection does not work.  It times out with errno=29:

openssl s_client -connect api.authorize.net:443

From a different server we see these two hosts are using different cerficates.  Namely, apitest.authorize.net is using the GEOTrust certificates.  The host api.authorize.net is using the EnTrust certificates.  Even though we've installed all the EnTrust certificates we can't seem to get it working and it didn't come up during sandbox testing and Authorize.net wasn't using those certificates. 

I have to say this rollout has been awful and why Authorize.net didn't use a standard trusted root certficate is beyond me.

We are using CentOS.