SSL Certificate Problem (Another Authorize.net Outage)

[danlagi32]

THIS PROBLEM HAS RETURNED! 

CURL ERROR: SSL certificate problem: unable to get local issuer certificate

Yesterday, working in the sandbox was fine (I've been working fine all week long), then this morning I started testing again, and first thing I get is this message!

I've done a quick search and found a couple of articles referencing this back in 2015, but it was supposedly solved.

Is anybody else having this problem? How did you fix it?  BTW, I have not changed anything on my system since yesterday when it was working fine.

Regards,

Dan Luevano

[CodeDawg]

Didn't work for me.  Win7/XAMPP v3.2.2.  

[tserface]

The sandbox was working for me until this morning.  I checked the certs and they are all still good for years to come.  It also broke on all of my 4 severs at the same time without any updates.  And, it seems to have broken for lots of other people here all at the same time.  I can use it if I disable SSL for curl, but this means directly modifying the API and, bigger issue, no security for transactions.  At least I can keep testing, but it would be nice to hear from Authorize.Net about what to do about this sudden issue.

[robin_cte]

Well I was hoping this would be fixed this morning. Like everyone, I was cruising along fine until the suddenly stopped working yesterday. Small mod to the api got it working for now. 

HttpClient.php , line 80, comment out:

curl_setopt($curl_request, CURLOPT_CAINFO, dirname(dirname(__FILE__)) . '/../../ssl/cert.pem');

This is NOT SECURE, not a permanent solution. I'm just testing so it lets me continue working.

So that cert is in a weird place, not sure where it came from. Was it part of the api install? I'm not cert savvy  so I've got to wait for our sys admin to wake up and look at it.

[robin_cte · Accepted solution]

OK, following a post on this thread:
https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Authorize-Net-Begins-I...

I replaced cert.pem with the file from 

http://curl.haxx.se/ca/cacert.pem

and all seems well

[nibarra]

This worked for me. Thanks!!!!!

[danlagi32]

Replacing the cert.pem also worked for me.  Is this a solution or a patch/work-around?

[cwilsontv]

Just to be clear about what's going on:

• apitest.authorize.net updated their SSL as of March 20th. (you can verify in browser by going there and checking).

• Curl can be configured to validate the SSL of the host it is connecting to before transfering data (which it should be).

• Curl can also be configured to use a specific CA (https://support.dnsimple.com/articles/what-is-ssl-certificate-chain/) to validate the SSL. This is why it looks at that pem. This is handy if you're using self signed certs or something like that, where your local machine doesn't have or know the CA to use to validate the SSL.
• The new SSL that the sandbox switched to doesn't validate with the CA that is provided by the library anymore. So now we get this error.
• Changing the pem to the one linked at http://curl.haxx.se/ca/cacert.pem works because that one has a CA that will validate the new sandbox SSL.
• As someone else suggested, you can also comment out line 80 of HttpClient.php. This line is telling curl to use that specific pem's CA to validate the host in the SSL request. This is not as insecure as someone stated because when you remove this setting CURL can default to it's own CA bundle, the system store, or other trusted stores depending on how it's built. It is still less secure, but it's not completely disregarding SSL validation. Eitherway on my windows test machine commenting it out doesn't work anyway.
• If using http://curl.haxx.se/ca/cacert.pem then besure to double check it works with production if your deployment process would push it, as unless someone tests it and verifies, there's no way to know if that CA will validate the production endpoint.
• I would consider this a temporary work around because if you're using https://github.com/AuthorizeNet/sdk-php (and why wouldn't you be?) redeploying that lib would wipe out the pem (and thus my integration tests are broken), so until it's updated it's no good for the sandbox.
• That github repo needs to update the pem like they did in 2015, but the best long term soultion would also be to provide us with a configurable path to the pem, so we can substitiue ones when needed, and also for when dev and production are different. I opened an issue: https://github.com/AuthorizeNet/sdk-php/issues/298

[danlagi32]

Thank you very much for your explanation! This is helpful. Now I know to also check the production side when I'm ready to go LIVE, and I'll know what to do if I encounter a problem.

Much appreciated!

Best Regards,

Dan Luevano

[tserface]

I'll chime in and say this worked for me as well.  I had to modify one of the files in the API because I couldn't find a way to set the cert path with a function (it's hardcoded), but this made it work.  Is this the solution?  Do we know why the other stopped working. According to the date in the file it should have worked until May 2022 for the one I have.

I'm happy to have a fix, but it would be interesting to know why it broke suddenly for so many people.

Tom

[nonrandom]

Had the same issue this morning but fixed it by replacing the /lib/ssl/cert.pem with the one from http://curl.haxx.se/ca/cacert.pem

Thanks for all the tips and information in this thread!