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

[RodG]

I've been working with my hosting company but they've run out of options.

Eeeek, a hosting company that can't sort out SSL/Certificate related issues.... If I were you I'd be seeking another host. Fast!.

Cheers
RodG

[mick9876]

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.

[lhungil]

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.

[RodG]

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

[one tall man]

I am also getting the same errors from Paypal checkout.
Tried to follow this page https://www.zen-cart.com/showthread....er-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?

[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?

[RodG]

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

[one tall man]

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 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.

[one tall man]

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?

[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, 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".