Hi,
I am having difficulty setting up the uc_payflowpro module where I keep getting this error in the Watchdog table:
uc_payflowpro: Connecting to PayFlow server failed: %error a:1:{s:6:"%error";s:123:"error setting certificate verify locations:
CAfile: /sites/all/modules/uc_payflowpro/cacert/cacert.pem
CApath: none
The issue it seems is that the cURL library can't find the cacert.pem file and I have tried all the possible ways/locations where I can the put this file but cURL still can't find it. I am using the payment gateway in "Test" mode and entering a test credit card number (Visa/4111111111111111) along with a CVV number of 100.
Here's my configuration:
Windows 2003 server with a standard WAMP installation:
Apache 2.2.6
PHP 5.2.5
Drupal 6.4,
Ubercart 6.x-2.0-rc5,
UC Payflow Pro 6.x-1.1-beta4
Any help will be much appreciated !!
Thanks,
Kamal
Comments
Comment #1
kwinters commentedSorry, I thought this one was already answered, but it was a similar issue and not this one that I was thinking of. This kind of configuration on a Windows box appears to be a pain, and people have run into it before but I need someone to help me write instructions on how to set it up for Windows in the README.
The first thing to do is go in _uc_payflowpro_submit_xml and var_dump $certpath, file_exists($certpath), etc. Until the path actually resolves to a file, you'll need to keep fiddling with it. If you can use that path to get to a file via terminal and the submit still doesn't work, it's probably a permissions issue.
My path is /etc/httpd/ssl/certs/cacert.pem since mine lives outside the site root. It looks like you have it inside the site, which is OK (but not ideal). However, if your path starts with a slash it probably won't work, since it's relative to the drupal root folder.
Comment #2
kwinters commentedStatus change.
Comment #3
jbrinley commentedI was having the same issue with 6.x-1.1-beta5. file_exists($certpath) returned TRUE.
I uncommented lines 889-890 in uc_payflowpro.module:
This allowed me to connect, but I'm not sure if that's wise.
Comment #4
kwinters commentedIt disables the man-in-the-middle avoidance via certs, which is a small but real threat. Making the .pem files work is still preferable.
Comment #5
kwinters commentedReclassified to the actual problem. If anyone gets the .pem file to work in Windows, please post instructions and I'll put them in the docs.
Comment #6
retorque commentedI had this problem on a site running on 64 bit IIS. I was able to get it working by using an absolute path and using only forward slashes in the path, not backslashes. I am not certain which one actually solved the problem (I will test if I have time and the client doesn't mind, but I don't have a similar environment set up myself).
While troubleshooting, we temporarily hardcoded the path on line 886 (curl_setopt($ch, CURLOPT_CAINFO, $certpath);) instead of using the $certpath variable, and it worked with backslashes, so it seems more likely that the absolute path was the fix, not the forward slashes. This client had to install files from several different versions of PHP and MySQL to get cURL to work on 64 bit Windows, so it is possible that some part of the installation caused cURL to interpret relative paths as relative to its own installation directory rather than the Drupal root as kwinters mentioned above.
Comment #7
kwinters commentedGreat, thanks. I made some README changes to suggest an absolute path; currently it's just in the devel release but it will go out next time I make a release.
Other paths in Drupal seem to work fine with forward slashes so I don't think that was it either.