Authorize.Net DPM fails with an SHA-256 SSL cert

Question

I am using the Authorize.Net DPM (Direct Post Method) integration on one particular eCommerce system that I manage.

We have renewed our SSL certificate for this site, and the new SSL cert uses SHA-256 rather than SHA-1, as is recommended for additional security.

However, now AUthoeize.Net can no longer post back to my server. When processing a payment, I receive the message:

An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.

from the URL https://secure.authorize.net/gateway/transact.dll, rather than being sent back to my code where I can display the "payment successful" page. Upon reseraching this, I believe the issue is that Authorize.Net's servers don't support SHA-2 certificates:

Does anyone know if Authorize.net accepts the newer SHA2 encryption? Our production servers which use this type of certificate do not receive the RelayResponse.

We found an article on SHA2 encryption issues with WIN2003 servers KB968730. We know Authorize.net uses Win 2003 servers based on http headers, which tell us IIS6.0.

---

We just established that is a real issue with Authorize.Net. We were able to purchase a SHA1 certificate and we are now able to receive the Relay Response from Authorize.NET. Authorize.NET Relay Response does not handle G2/SHA256 certificates. This will become a major issue in 2014 when SHA1 certifictions will not be obtainable from vendors eg. GoDaddy etc.

I have contacted Authorize.Net support but they seem to not even understand how their own product works, because the responses I get from them make no sense:

We have no announcements regarding the use specifically of SHA-2 hashes to connect to our servers at this time. Notices of any changes to the integration methods will be available in the merchant interface, as well as on the developer center at developer.authorize.net if that change occurs.

I'm not connecting to their servers. They're connecting to my server... so since their support is of no help... how can I resolve this? Is it safe/wise to not use SSL for the x_relay_url DPM postback URL? That seems to be the safest suggestion but I am hesitant to do this.

Answer 1

The resolution I went with was to get an SSL certificate with an SHA-1 signature algorithm, rather than SHA-2.

The issue that SHA-2 certs are rejected by Authorize.net's servers has been reported to their systems engineering team, but I do not know if they will correct this.

Answer 2

I have just run into this problem myself.

I can verify that in my tests, when I switched my x_redirect_url parameter to use a non-ssl host it started redirecting properly back to my site. I can also verify that Authorize.net support does not know how their own products work; I had to explain to them how the x_redirect_url works and got no usable info from them regarding any kind of validation they might be doing on the redirect URL that could cause their system to refuse to redirect.

I thought it was due to a domain name mismatch in my dev environment so I just forced my dev environment to use a non-ssl redirect. Then when I launched my new site I discovered that the problem persisted with SSL redirects on my production site, so I've just switched it back to using non-ssl redirects on my production site temporarily until I get this sorted out.

I have not yet regenerated my ssl cert because I'm not sure if it's using SHA1 or SHA2 and I don't want to regenerate it and reinstall it until I'm sure the cert is SHA1.

I'm having a hard time determining which SHA version it uses because the Thumbprint Algorithm shows SHA1, but then I see SHA256RSA for the Signature Algorithm and sha256 for the Signature Hash Algorithm. So, if anyone knows if that means I have SHA1 or SHA2, please reply to this reply.