We are using CIM to process payments. We have a recurring cron job that seems to be running fine. But when attempting to create a new payment profile, we have been experiencing this error message since 5:53 AM EST.
[2014-09-27 09:53:36][----Request----]
MASKED
----CURL ERROR----
Problem with the SSL CA cert (path? access rights?)
All new orders placed between then and now have been declining on the front end with a null error message due to this SSL issue. From reading around before posting this, it's my understanding that this is not a new issue. Is anyone else experiencing this?
Solved! Go to Solution.
09-27-2014 06:45 AM
I spoke with Rackspace and they figured out the problem. Apparently, it was an issue with the NSS package issued by RedHat for CentOS. It affected any servers running CentOS trying to connect via SSL. Rackspace restarted my Apache and it fixed the issue.
Just confirmed that even CIM in Test Mode is throwing off declines due to the SSL issue. This is 100% an Authorize.net outage.
09-27-2014 07:53 AM - edited 09-27-2014 07:54 AM
Hello @jmagaro88
Is there any more detail you can provide about the error? SSL connection logs would be helpful.
Richard
09-27-2014 08:18 AM
I don't think there's much more I can provide. We don't currently have a more detailed log. I just keep getting a CURL error when our system is trying to connect with CIM. I got it on creating a new transaction and even attempting to void a transaction from yesterday that hadn't settled yet from inside our backend. Below is the full text of the first log when the error popped up. It looks the same in all the subsequent logs.
[2014-09-27 09:53:36][----Request----]
MASKED
----CURL ERROR----
Problem with the SSL CA cert (path? access rights?)
[2014-09-27 09:53:36][----Response----]
[ Time Taken for the API CALL : 0seconds ]
[2014-09-27 09:53:36][----Request----]
MASKED
----CURL ERROR----
Problem with the SSL CA cert (path? access rights?)
[2014-09-27 09:53:36][----Response----]
[ Time Taken for the API CALL : 0seconds ]
[2014-09-27 09:56:08][----Request----]
MASKED
----CURL ERROR----
Problem with the SSL CA cert (path? access rights?)
[2014-09-27 09:56:08][----Response----]
[ Time Taken for the API CALL : 0seconds ]
[2014-09-27 09:56:09][----Request----]
MASKED
----CURL ERROR----
Problem with the SSL CA cert (path? access rights?)
[2014-09-27 09:56:09][----Response----]
[ Time Taken for the API CALL : 0seconds ]
[2014-09-27 10:04:01][----Request----]
MASKED
----CURL ERROR----
Problem with the SSL CA cert (path? access rights?)
[2014-09-27 10:04:01][----Response----]
[ Time Taken for the API CALL : 0seconds ]
[2014-09-27 10:04:01][----Request----]
MASKED
----CURL ERROR----
Problem with the SSL CA cert (path? access rights?)
[2014-09-27 10:04:01][----Response----]
[ Time Taken for the API CALL : 0seconds ]
09-27-2014 08:28 AM - edited 09-27-2014 08:30 AM
We have a backup checkout system with Volusion that does not use CIM. It stores customer information and credit card data on Volusion servers. That is working fine, so it must be an issue exclusively with CIM and the SSL certificate for the API or something.
09-27-2014 08:31 AM
I spoke with Rackspace and they figured out the problem. Apparently, it was an issue with the NSS package issued by RedHat for CentOS. It affected any servers running CentOS trying to connect via SSL. Rackspace restarted my Apache and it fixed the issue.
Customers would find it much easier to self-diagnose if Authorize.Net had a published API/system status page that updated automatically with the results of external monitoring systems
This should be a standard practice
I've seriously contemplated posting an unofficial one with the results from our Pingdom account (which I have set to monitor the CIM API -- since it has been going down so much, it is helpful to know straight away if it's me or them) for the benefit of the developer community
09-28-2014 11:24 AM