(60) SSL certificate problem: unable to get local issuer certificate

I have solved the problem by going to http://curl.haxx.se/docs/caextract.html. However, instead of downloading the latest cacert.pem, I jumped down a paragrapgh to here:

*RSA-1024 removed

Around early September 2014, Mozilla removed the trust bits from the certs in their CA bundle that were still using RSA 1024 bit keys. This may lead to TLS libraries having a hard time to verify some sites if the library in question doesn't properly support "path discovery" as per RFC 4158. (That includes OpenSSL and GnuTLS.)
The last CA bundle we converted from before that cleanup: an older ca-bundle from github.*

I downloaded the older ca-bundle and it worked a treat. Happy days.

Glad that is working for you.. However this entire thread and the "issues" you have been experiencing highlight two simple facts. First your hosting provider does not know how to properly configure their servers (or you would not need to specify a custom CA bundle in this case). Secondly your hosting provider is not keeping up to date with patches, upgrades, and security (or you would not need to use an out of date CA bundle). I would echo the sentiments posted earlier by another member.

It is time for you to move your e-commerce store to a hosting provider better suited to e-commerce hosting.

mick9876:

I downloaded the older ca-bundle and it worked a treat. Happy days.

Congratulations at being able to find a solution that your host couldn't. I don't consider this to have been an easy one to resolve. Well done.

However it would be amiss of me to say this solution is a good fix because it potentially opens up a security hole on the server. You probably shouldn't let that bother you in itself though, you have done what is needed, and it is ultimately the hosts responsibility to keep the ca's up to date.

Cheers
RodG

I am also getting the same errors from Paypal checkout.
Tried to follow this page https://www.zen-cart.com/showthread.php?213892-Curl-error-%2860%29-SSL-Certificate-problem-Unable-to-get-local-issuer-certificate but so far no luck.
Downloaded cacert.pem from both http://curl.haxx.se/docs/caextract.html and http://filehostuk.com/downloads/cacert.rar
The attached screen shot is all I am getting from curltester.php, nothing like in the screen shot posted at the link above.
What am I doing wrong?

Argh! I was using an old version of curltester.php and the new version from 1.5.5 shows successful test to all destinations.
But I am still getting the error. How should I investigate further?

one tall man:

Argh! I was using an old version of curltester.php and the new version from 1.5.5 shows successful test to all destinations.
But I am still getting the error. How should I investigate further?

Exactly when/where are you getting this error? (Yeah, I know it is during checkout, but I/we don't know if this is when using the Express checkout, or whether it is when a user is logged in and steps through the checkout pages to the final click, which gives the PayPal popup).

Furthermore, the thread that you have jumped into here is referring to the error message that would only be found in the log files, so are the log files that "show the same error" newly created ones or are you possible looking at old files?

The thing is, I've just been to your store, added a product to the cart, tried the express checkout and was taken to the PayPal site as expected. I aborted the transaction at that point.

Next thing I did was create a store user account, and again, went right through the checkout process right up until the PayPal popup, at which point I again aborted.

I had no errors - BUT, I did note that your site is using a self-signed certificate, which will cause all browsers to produce a security warning, which needs the customer to accept this certificate before proceeding with the site SSL connection, but this is actually a different kettle of fish than what would cause the (60) SSL local issuer problem, which points right back to a problem with the cacert.pem file, but if that were the case, the cURL test script would almost certainly fail as well, which it isn't.

So, at this stage, I'm not seeing any problems at all, and the only step I've not done is click the PayPal buttons to finalize the transaction.

How did you test/check that you are still getting the error? Did you place an order in your own store, or are you waiting/watching for a customer to place an order? Have any customers tried placing an order since you've updated the cacert.pem?

Unless you've posted more information in another thread, you haven't really given us a great deal of information, and nothing personal, I always cringe when I read things like "I'm getting the same error" or "still getting the error" - because it isn't uncommon to find that it either isn't 'the same error' as discussed hijacked thread, or, in a case like yours (where you followed the 'fix' for the 'same error') the 'still getting the error' isn't always true , and often turns out to be a different error (IOW, the original error could have fixed, only to reveal another,, but the assumption being that it is still the same error). Putting it another way, until confirmed that it really is the 'same error' that you are currently seeing, and that the error log entries are new (since the cacert.pem update) we could all be running around in circles.

The other thing that I find a little unsettling is the fact that you discovered that you had originally used an older version of the curltester.php . How did that come to be? How come this file didn't get updated along with the rest of the files when the store was updated? What other files didn't get updated? Is it possible that the PayPal related files also didn't get updated as they should have done? Mixing files from different versions can often have unexpected results, which brings us back to the question as to whether you might have had two different issues - The now (possibly) fixed local issuer error, and now a different error relating to old paypal related files?

Sorry, but at the moment, I don't have any answers, just more questions.

Cheers
RodG

I am receiving the email notifications when the external customers are attempting to check out using Paypal Express Checkout:

From - Wed Jan 18 19:23:44 2017
X-Account-Key: account##
X-UIDL: 803
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-Path: [email protected]
Received: from https://www.vintageelectronics.ca ([1##.###.###.2])
by mail.########.ca with ESMTPA
; Wed, 18 Jan 2017 17:17:52 -0500
Date: Wed, 18 Jan 2017 22:17:51 +0000
To: "Vintage Electronics Canada Inc." [email protected]
From: "Vintage Electronics Canada Inc." [email protected]
Reply-To: "Vintage Electronics Canada Inc." [email protected]
Subject: ALERT: PayPal Express Checkout Error ()
Message-ID: #########@www.vintageelectronics.ca
X-Mailer: PHPMailer 5.2.16 for Zen Cart
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8

Problem occurred while customer was attempting checkout with PayPal Express Checkout.

Dear store owner,
An error occurred when attempting to initiate a PayPal Express Checkout transaction. As a courtesy, only the error "number" was shown to your customer. The details of the error are shown below.

(60) SSL certificate problem: unable to get local issuer certificate

Zen Cart message: An error occurred when we tried to contact the payment processor. Please try again, select an alternate payment method, or contact the store owner for assistance.

I blew away the old logs when upgrading and do not see any new logs under paypal payment module's logs folder.

The wrong version of curltester.php which I initially used was left over on another virtual host which I thought was upgraded to 1.5.5 but in reality it was not yet. As I removed ./extras from vintageelectronics.ca virtual host, I used the other host's curltester.php to do the test. When I realized it was different, I restored ./extras on this host from 1.5.5 distro and re-ran the test.

I just had an idea:

Does it matter that TCP port 30,000 is forwarded to one specific host on the LAN and not to the web server running the store?

I have switched the paypal module to sandbox mode and tried to check out. I did not see anything in the payment methods (no radio buttons or icons at all) but still proceeded to checkout and it was listing paypal. When pressing 'check out' a new window popped up with the red rectangle above the invoice items stating:

We are sorry for the inconvenience. The PayPal account authentication settings are not yet set up, or the API security information is incorrect. We are unable to complete your transaction. Please notify the store owner so they can correct this problem. (10002) 10002 Security error - Security header is not valid

I guess this was due to the sandbox mode and is a red herring, as when I switched over to live mode, I could proceed further to Paypal login page, which is not letting me into the same account as the store owner, which is the only one I have. So I cannot myself test any further. Only one observation: when I am clicking on the big blue Paypal login button, Firefox throws a notification about "clickjacking".

one tall man:

I am receiving the email notifications
From - Wed Jan 18 19:23:44 2017
Received: from www.vintageelectronics.ca
From: "Vintage Electronics
Problem occurred while customer was attempting checkout with PayPal Express Checkout.
(60) SSL certificate problem

As you can see, this email was dated 18th Jan.
It was 19th Jan that you reported the issue here along with the info that you'd updated the .pem

On this basis, it is theoretically possible that this particular problem has actually been fixed already (19th) and you've had no failures (or sales) since the fix.

Yeah, I know its also possible that you may have did the .pem update on or before this attempted order came in and that you didn't post about it until after, but going back to my previous concern that "still getting the error" may not even be the same error, I'd really like to see (or have confirmation) that it is indeed the same local issuer error after the .pem update on the 19th, or perhaps if you could at least confirm that you did the .pem update on or before the 18th when this order was attempted. With the current information and dates given, the problem has been fixed but you/we simply dont know it yet because there hasnt been any attempted orders since.

Cheers
RodG

one tall man:

I
I just had an idea:

Does it matter that TCP port 30,000 is forwarded to one specific host on the LAN and not to the web server running the store?

No..... But, how, where, when does LAN even come into any of this anyway? If your store is hosted on your LAN (private IP) this opens up a whole new avenue of possible problems and causes. It could be something as simple as a local firewall blocking the traffic. (a "webserver running the store" could mean LAN or WAN).

Cheers
RodG

one tall man:

I have switched the paypal module to sandbox mode and tried to check out. I did not see anything in the payment methods (no radio buttons or icons at all) but still proceeded to checkout and it was listing paypal. When pressing 'check out' a new window popped up with the red rectangle above the invoice items stating:

We are sorry for the inconvenience. The PayPal account authentication settings are not yet set up, or the API security information is incorrect. We are unable to complete your transaction. Please notify the store owner so they can correct this problem. (10002) 10002 Security error - Security header is not valid

I guess this was due to the sandbox mode and is a red herring,

Correct (red herring). However, this does imply that you no longer have a 'local issuer certificate' problem.

one tall man:

as when I switched over to live mode, I could proceed further to Paypal login page, which is not letting me into the same account as the store owner, which is the only one I have. So I cannot myself test any further. Only one observation: when I am clicking on the big blue Paypal login button, Firefox throws a notification about "clickjacking".

OK, so to help out - I've just completed a PayPal order from your store - I had no problems at all - The payment went through

Transaction ID: 97882686VU595912W
Payment Type: PayPal Express Checkout (instant)
Timestamp: 2017-01-22T08:14:40Z
Payment Status: Completed
Amount: 2.25 CAD

It appears that your .pem update probably did fix the issue after all.

Please cancel this order and provide a refund.

Thanks
RodG

ps. Chrome didn't give any warnings about clickjacking, so I don't know what to make of that.

Oh, so that was you! I should've guessed by Australian doing a store pick up! Someone already sent you a follow up email, you can ignore it. Doing the refund now.
You are right, everything in Paypal module is working fine, thanks a 10^6 for your help and patience with my questions!

one tall man:

Oh, so that was you! I should've guessed by Australian doing a store pick up!

I could have been visiting your area ;)

one tall man:

Someone already sent you a follow up email,

Yeah, apparently 'someone' didn't read the comment I made when I placed the order ;) I wasn't really impressed about that to be honest. What would have happened if I did select something other than local pickup? I suspect the unwanted order could be on its way to me already.

one tall man:

you can ignore it.

I already did.

one tall man:

Doing the refund now.

Got it. Thanks.

one tall man:

You are right, everything in Paypal module is working fine, thanks a 10^6 for your help and patience with my questions!

No problem. It was fortunate that you had some pretty cheap products. I was happy to 'risk' a couple of bucks to try to help out (and confirm my suspicions), but anything more than that you'd have been on your own waiting for a real order, which you could have lost if the problem still existed.

BTW, after doing that, I followed up initiating another order, but this time using firefox, and I still didn't get any warnings about 'clickjacking' - so that remains a mystery. I suspect it could be the result something related to how the page is/was rendered - for example, on a smaller screen it is possible that the 'checkout' button was overlapping one of the other buttons (which is basically what 'clickjacking' is all about) so this may still warrant further investigation 'cos it could cause a loss of sales.

I'd also suggest that you do something about the self-signed SSL which causes most/all browsers to produce a scary warning, which will cause lost sales. Personally I'd rather shop on a site with a self-signed certificate than one with a shared certificate (they are more trustworthy), so I had no qualms about clicking through and accepting the certificate - but most people won't. - You should either get the certificate signed by one of the CA's - OR (what I do) is set up to use 'Cloud flare', which will 'hide' the fact that it is self signed (or non existent). If this isn't an option, then don't use SSL at all. Most folk wan't notice or care, and even those that do see the 'not secure' that is displayed in the address bar these days, they are still more likely to proceed with the purchase than the scary popup and need to accept the self signed cert before they can continue.

Oh, another option - Most hosts these days provide a free SSL from "lets encrypt' (often without advertising it), so you may find that you can remove your self signed cert, and you will still have an SSL enabled site.

Cheers
Rod