We're getting this error when trying to connect to the Live server:

SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

We had no problems on the test server, of course, because the test server isn't doing host/peer verifications.

Comments

This is a major issue occuring with Linkpoint right now. All of our Linkpoint sites cannot connect to gateway.

You can temporarily resolve this issue by setting the following options in curl:

  curl_setopt ($ch, CURLOPT_SSL_VERIFYHOST, 0);
  curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, 0);

Those options are ALREADY SET in the module for the test transactions. Just copy and paste these two lines into the else block for that if statement, so they are set for the 'live' server transactions as well.

Just got off the phone with merchant services over there.... they got a new SSL cert for their site and there are major problems for every merchant. They are working on it.

He suggested the same as I did above until they resolve the issue. Set verify host and peer to 0.

Priority:Normal» Major

Do you think it could be that we're using the wrong URL for transactions? When I called, the recorded message said to be sure we were using www.firstdata.com. Just a thought, though I'm sure your support person would have let you know if it was that easy.

That is for accessing the virtual terminal, not the API call. I told him I fixed it by adding those two options and he said thats exactly what he is telling people to do.... so yeah i guess we're good for now. Incredible that their new SSL cert just suddenly broke EVERY site from interacting. I'd be embarrassed to be them right now

We also have a customer experiencing this same issue. I've applied the fix shown in #1 and it appeared to work. Thanks for this.

Thanks a brazillion for the responses; we've been beating our brains out on this one.

curl_setopt ($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, 0);

That fix didn't work for me. Any other suggestions?

UPDATE: On the other hand, it does work!

Nope, that is the suggested I got directly from First Data.... hmm do you know what error you are getting? It may be unrelated to this. Try and give more detail. When did it start happening?

I'm running a live site and an all new beta site. My FTP was on the beta site, not the live site, so what I was updating was not where the issue actually was. I realized it when I uploaded version 1.8 about 4 times and nothing changed. :/

Thanks!

Any info on whether or not they've resolved the issue? I'd like to change my settings back for security, but also don't want to risk failed orders...

I had a customer with this same issue. I just got off the phone with LinkPoint support where we found we could fix the problem by rotating a some of curl_setop statements to the order shown below.

// Set the cURL options
// Determine the posting URL
if (variable_get('linkpoint_api_transaction_server', 'live') == "test")
{
curl_setopt($ch, CURLOPT_URL, UC_LINKPOINT_TEST_URL);
} else {
curl_setopt($ch, CURLOPT_URL, UC_LINKPOINT_LIVE_URL);
}
curl_setopt($ch, CURLOPT_VERBOSE, 1); // Present verbose error output, to standard error
curl_setopt($ch, CURLOPT_POST, 1); // POST Request
curl_setopt($ch, CURLOPT_POSTFIELDS, $xml); // Data to send in the POST request
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); // Puts output to a returned string
curl_setopt($ch, CURLOPT_SSLCERT,variable_get('linkpoint_api_transaction_key', '')); // The public cert key generated by Fir$ Datadata

Someone may want to confirm the above and issue a patch.

To manually do it, replace lines 292 - 305 in uc_linkpoint_api.module.

Please note, this worked for my customer but I can't promise it will work for others until a maintainer checks it out and posts a patch.

-George Aiello

George, yes that is the solution that we came up with above to resolve the situation. Linkpoint also confirmed. Jason, I'm at DrupalCon and won't have time to call Linkpoint to ask about that. Are you here as well?

I'm unfortunately not at DrupalCon :(

I imagine, though, that the fix from #11 is not due to the re-ordering of the curl options, but that it also disables VERIFYHOST and VERIFYPEER. That, however, isn't a longterm secure solution, and I'd be surprised if Linkpoint endorsed it as a permanent solution. From this site:

verifyhost just checks the details of the cert (Common Name and that it matches the hostname) whereas verifypeer actually checks that the certificate is valid.

Status:Active» Fixed

Linkpoint tech support said it was fixed and I confirmed with an order using the existing code, so you can undo your changes.

What a failure by first data... thanks for looking into this.

We're still having the same issue, even though LP is assuring us it's fixed.

This is from my MAMP dev machine as well as WAMP stage and production servers.

Anybody else still out in the cold?

Have you tried on a remote server?

When I tried connecting to LP from my local MAMP install a few weeks ago I couldn't. I was pulling my hair out trying... then I tried it on our remote dev server and it worked. Try that

What OS is the server that worked for you? I'll spin up a cloud server on that OS and test off of that platform.

LP is telling us the 64-bit Win2K8 using IIS (a brick-wall client requirement) won't support the API. That doesn't make a ton of sense, but I'd like to verify that this is an OS issue before we bury time in trying to implement the SOAP service.

We have it working on a CentOS server and Red Hat server. Not sure the versions right now, but that shouldn't matter. I hate windows servers... good luck with that. I have no clue how LP could allow their API to be distributed w/o IIS support. Is this that set up specifically or all IIS servers?

Spun up a Ubuntu instance on the cloud, threw a copy of the site on there, and it worked like a charm. It is indeed an OS issue.

I'm with you on LP not supporting Win2008. It's 2011, yeah? Three years isn't enough to fix that issue?

Sure wish I could convince the client to use Authorize.net.

Thanks again bkosborne

We also implemented the above cURL fixes to deal with their bad SSL certificate, but FirstData (Linkpoint) told me their certificate is fine now. I removed that fix (reverting to original code) and it still works. So no more SSL issues from their end it seems.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.