Sounds like an issue with your hoster. Since the GitHub address is using "https", you need to have a valid SSL "client" to connect. In your case your website is the client and the SSL certificate for the server likely isn't valid.

The only thing we could do on our end is to move the package to a different location which doesn't require SSL.

The issue appears on two different site with different hosters. Maybe the have the same problem. Someone else who has the smame problem (or not)?

I have the issue on localhost (I think I don't have SSL installed there) and on my cheap hoster (I planned to contact their support).
But it works fine on my test server.

I've seen this with extensions that serve packages from GitHub. I don't have good data on what environments it happens in, I just know my localhost can't install my own extensions (published here) when I try to test that aspect of things; I have to use local packages or test in other ways.

I am having the same problem with multiple sites on multiple hosts.

Filed a support ticket with my hoster. Hopefully I get a useful answer which will help us here :)

Evidently I duplicated this issue and was directed here.

I'm not having any luck updating this either. I've uploaded the package to my tmp folder - not working either. My host is Rochen

Installing the manually downloaded package should work just fine. That wouldn't be related to this issue and sounds more like a corrupt installation then.

After uploading the file and clicking on the "Install from Directory" tab in the extension manager, the path shows the following:

/home/my-account/public_html/tmp

Am I supposed to add the filename to this path "/pkg_weblinks341.zip" ? because that doesn't work. Not adding it doesn't work...

Just use the "Upload Package File" tab and add the file you downloaded to your local system to that field.

The file has been uploaded to the tmp directory. The following is the path used for "Install Directory".
/home/my-account/public_html/tmp/pkg_weblinks341.zip

Results in the following error...

Error
Please enter a package directory.

Unable to find install package

Does it need to be unzipped first?

Using the "Upload Package File" does not work - multiple errors. That's why I'm now trying to install from a directory.

Uninstalling the following and uploading the package file seems to have worked.

With install from package you need to mention the zipfile, with install from directory you need to mention the directory where you extracted the package in.

it may not be related, but similar SSL certificate issues happen when using SMTP on PHP 5.6+ (see phpmailer wiki page).

Doesn't seem to be related to the PHP version.
Testserver with PHP 5.6.9 works fine. Hosted one with PHP 5.5.10 has an issue.

I have been chasing this bug for two days. I think I have the solution - those affected please read and report back...

First - I did the same process on two locations. One was on my shared hosting account the other on my dedicated server. On shared it worked just fine, updated from joomla 3.3x to 3.4.3, then this dreaded update showed up, I clicked it, hit update, bam. Worked. On dedicated, I get the issue with the certificate error. Have been troubleshooting forever it seems.

What I've found is this... The shared hosting where this is working for me is using an older version of cURL (7.21) which still supported 256bit ciphers. This weblinks extension update is being hosted on S3 Amazon. AWS still supposedly uses a root key that is 256bit even though their site key is 2048. Since their root is at the top of the chain the 256 bit comes into play.

My dedicated server is running a newer cURL (newer than 7.33 which removed 256bit capability for security sake). So it seems that when Joomla goes to get the update from git all is good because that is the git cert, it is then redirected to an S3 URL which presents the 256bit root key and flops.

As I see it there are 3 fixes...

turn off verify for the ca (not a good one)
modify cURL so it is forced to use older/smaller keys (not a good one)
Amazon get off their butts and update the keychain (ideal - but there are threads out there of people complaining since spring)

No great solution. I wish Joomla had a checkbox to temporarily turn off ca verification for updates. I still need to verify that this is truly the case but I think this is the core issue. If you are suffering this problem, do this:

Go into phpinfo if you have one or login to your backend and go to SYSTEM/SYSTEM INFORMATION/PHP INFORMATION tab

Find the section on cURL and report back what version you have. If it's newer than 7.33 this is very likely the issue.

Sorry bad phrasing/terms - it's not the bit key length but method of signature that's at issue. AWS root cert is signed using sha1 and cURL requires higher.

For me that seems to be the other way around:
Hosted one runs cURL 7.16.4 (on PHP 5.5.10) and fails.
Own test server runs cURL 7.42.1 (on PHP 5.6.9) and works.

But knowing that they use different certs is a good hint for sure. We also may face multiple issues.

Updated no errors on shared hosting for me.

Suspect its the Cert the Hosting company uses which causes the problem in some cases.

In many cases it is the certfile.pem causing the issue. If it doesn't have the root cents that were pulled for weak ciphers it will also fail regardless of version of curl. Lots of systems have ancient ca files too.

On the other hand a higher version of curl could have been compiled in a way to allow the outmoded certs. We need more data.

This is insane. Frankly shame on the devs for not error trapping and allowing us to ignore the feet error. (A la the way chrome deals with outdated site certs... "Ya sure you want to go there?")

On Jul 25, 2015, at 5:34 PM, Webdongle notifications@github.com wrote:

Updated no errors on shared hosting for me.

Suspect its the Cert the Hosting company uses which causes the problem in some cases.

—
Reply to this email directly or view it on GitHub.

cURL support enabled
cURL Information 7.38.0
Age 3
Features
AsynchDNS No
Debug No
GSS-Negotiate No
IDN Yes
IPv6 Yes
Largefile Yes
NTLM Yes
SPNEGO No
SSL Yes
SSPI No
krb4 No
libz Yes
CharConv No
Protocols dict, file, ftp, ftps, gopher, http, https, imap, imaps, pop3, pop3s, rtsp, smtp, smtps, telnet, tftp
Host x86_64-unknown-linux-gnu
SSL Version OpenSSL/1.0.1e
ZLib Version 1.2.7

j! 3.4.3 brand new global cert issued just a week or 2 ago.

PHP Built On Linux host.hallhome.us 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64
Database Version 5.6.23
Database Collation utf8_general_ci
PHP Version 5.4.42
Web Server Apache/2.4.12 (Unix) OpenSSL/1.0.1e-fips mod_bwlimited/1.4
WebServer to PHP Interface cgi-fcgi
Joomla! Version Joomla! 3.4.3 Stable [ Ember ] 2-July-2015 16:00 GMT
Joomla! Platform Version Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT
User Agent Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36

Not working:
PHP Version 5.4.38
cURL Information 7.37.1

PHP Version 5.5.22
cURL Information 7.37.1

Working:
PHP Version 5.4.43
cURL Information 7.19.7

If any of you has shell access to a server where it doesnt't work, can you try the following command?
openssl s_client -connect github.com:443

That connects fine for me. I can see why as they are SHA256.

Try the same thing with s3.amazonaws.com... you will see that there is a 3 deep certificate chain and also that they use SHA... github uses SHA256. This update goes to github then is 301 redirected to https://s3.amazonaws.com/github-cloud/releases... It seems to fail on this second part because S3 is using outdated tech in their certs and the newer cURL is not having any of it.

Ah I see.
https://github.com/joomla-extensions/weblinks/releases/download/3.4.1/pkg_weblinks_3.4.1.zip
is redirected to
https://s3.amazonaws.com/github-cloud/releases/16672606/5ed8b4ca-3181-11e5-91f5-3689f9dd7382.zip?response-content-disposition=attachment....

So this explains why the manifest XML works fine (which is served from GitHub) and only the package.zip is failing.

Exactly! So any package that is hosted in S3 regardless of origin link will be failing. I'm sure there are other hosts that have similar cert problems. Think about your regular browsing habits, how many sites do you run into that give the SSL error but are legit? Try going to Boy Genius Report page via SSL in chrome - https://www.bgr.com/ - same deal there. They probably don't even know it. Only way I found that one was that I run SSL everywhere plugin in Chrome so it tries to load SSL every chance it can.

I am sure this problem isn't going anywhere. The ideal solution (perhaps for Joomla 3.4.4) is to give us the option to see the full cert issue and allow the admin to decide if it's ok to proceed - just like Chrome/Firefox do now for less than ideal SSL pages.

SSL certificates are validated according to a hierarchical structure. Every server has a list of certificate authorities (CA) to trust and a chain of trust to validate.

If CA list is not updated by your hosted or intermediate certificates can't be validated, then you get the error about "unable to get local issuer certificate...".

For instance, you can review how a SSL certificate is validated (a handy service: https://www.digicert.com/help/):

DNS resolves 's3.amazonaws.com' to 54.231.0.216

HTTP Server Header: AmazonS3
Protocol Support

TLS 1.2, TLS 1.1, TLS 1.0
SSL certificate

Common Name = s3.amazonaws.com

Subject Alternative Names = s3.amazonaws.com

Issuer = VeriSign Class 3 Secure Server CA - G3

Serial Number = 4EA82FDF2AFFF220269994AF078C4FEE

SHA1 Thumbprint = 937BCB774637850BD570E5A3035AF0D8929F0388

Key Length = 2048 bit

Signature algorithm = SHA1 + RSA (deprecated)

Secure Renegotiation: Supported
This certificate does not use a vulnerable Debian key (this is good)
SSL Certificate has not been revoked
OCSP Staple:    Not Enabled
OCSP Origin:    Good
CRL Status:     Not Enabled

SSL Certificate expiration

The certificate expires October 27, 2015 (92 days from today)
Certificate Name matches s3.amazonaws.com
Subject s3.amazonaws.com
Valid from 27/Mar/2015 to 27/Oct/2015
Issuer  VeriSign Class 3 Secure Server CA - G3

Subject VeriSign Class 3 Secure Server CA - G3
Valid from 08/Feb/2010 to 07/Feb/2020
Issuer  VeriSign Class 3 Public Primary Certification Authority - G5

Subject VeriSign Class 3 Public Primary Certification Authority - G5
Valid from 08/Nov/2006 to 07/Nov/2021
Issuer  VeriSign, Inc.
SSL Certificate is correctly installed

Congratulations! This certificate is correctly installed.

The only final solution is ask hosting support to upgrade SSL installation. Some hosters frequently give you as answer to hack into PHP code and disable SSL certificate validations in CURL connection (PHP's internal browser).

CURLOPT_SSL_VERIFYPEER      => false,

NOTE: 's3.amazonaws.com' has Signature algorithm = SHA1 + RSA (deprecated) ....

I wonder what we can do then on our side. Maybe add a more explanatory error message which tells:
"We're sorry, due to outdated server infrastructrure of your host I can't download the package for you. You need to download it at <insert link> and install it manually"

I think it's the other way around. Server infrastructure is up-to-date but certificate is not.
https://forums.aws.amazon.com/thread.jspa?threadID=164095

Ah, then the openssl or curl version itself doesn't matter, Only the version of the cacert.pem file matters? That would explain some things we see.

That's how I understand the explanation and I think it's the same as what @peetwright is trying to say.

Hi gang - @Pinkeltje and @Bakual I think we are all discussing the same thing but there are some disconnects since we are talking server to server it's tough to say the problem is at the server ;)

That aside here is what I found... the certificates in the AWS chain are what are broken.

Many of us, myself included, have a brand new/fresh cacert.pem file as that was one of the first things we tried. The issue with this file is that the people who maintain it (Mozilla and haxx.se) have removed top level CA certs of providers who had weak signatures. Verisign was one of those I believe.

Secondly, the developer of cURL as of version 7.33 told cURL to not accept weak certificates.

So unfortunately the only true fix is that the amazon server update it's full cert chain.

The workaround I suggested can be put into Joomla by the core developers and would make the process work just like our regular browsers and ask us if we are ok with this and proceed or not. The PHP code would be trivial - along the lines of "if user is ok with this then CURLOPT_SSL_VERIFYPEER, false" but only if the user says it is ok to do so.

Hope this helps. FWIW, yesterday after figuring this out, I updated a handful of sites at various levels with various plugins and such. The weblinks update in question is the only one that kept coming up. Everyone else made it through without issue.

I don't think using CURLOPT_SSL_VERIFYPEER is a good idea. Even if opt-in. Once activated people would forget and disable some security on their site permanently.
I'd rather tell them to download the file manually and work from there until Amazon updates its certs.

I agree it's not a great idea - but it is in all the browsers today. Perhaps not a permanent ignore checkbox but a message allowing a one-time exception like the browsers work?

Worst case - at least a useful error message would be key. Had I been given info on what was going on I wouldn't have burned 25 hours researching this. That stung and ruined a perfectly gorgeous weekend! :)

On Jul 27, 2015, at 1:34 PM, Thomas Hunziker notifications@github.com wrote:

I don't think using CURLOPT_SSL_VERIFYPEER is a good idea. Even if opt-in. Once activated people would forget and disable some security on their site permanently.
I'd rather tell them to download the file manually and work from there until Amazon updates its certs.

—
Reply to this email directly or view it on GitHub.

Quick and dirty solution could be joomla/joomla-cms#7570
Just linking the package so the user can try and download it manually.

I looked at catching the SSL error but that's not that easy to do.

The error itself is more important. To someone who hasn't experienced it this is a scary thing especially if you start googling the symptoms. Then people (myself included) start monkeying about with cURL and certfiles and the next thing you know their hosting environment is hosed up. Thankfully not my case - but I can see how that would happen.

The URL is there - it's not click-able which is ok by me. But that error is useless. If you want to pursue this approach I'm all for it, but revise the error itself to state something like:

This update failed automatic installation because the target server is using an outdated SSL configuration. If you know the vendor, let them know to update their certificates. In the meantime, you can work around this error by manually downloading the package here #URL# and installing it manually using the extension manager install function.

Just my $0.02 worth :)

On Jul 27, 2015, at 3:29 PM, Thomas Hunziker notifications@github.com wrote:

Quick and dirty solution could be joomla/joomla-cms#7570
Just linking the package so the user can try and download it manually.

I looked at catching the SSL error but that's not that easy to do.

—
Reply to this email directly or view it on GitHub.

The error text itself isn't being written by Joomla (everything after Error connecting to the server: comes from the HTTP request that was made). So still not something easy for us to deal with in the core platform as it means matching literal strings (and hoping they don't ever change) to figure out how to process them.

Ah, I was afraid of that. Lots of PHP cURL examples have error trapping looking for strings but you're spot on, who knows what the string will be down the road or in localized versions of linux. Maybe the answer can be as simple as a Joomla update message?? Along the lines of the one that came with 3.4 telling users they should edit and save/close their language file. At least it's something.

On Jul 27, 2015, at 3:46 PM, Michael Babker notifications@github.com wrote:

The error text itself isn't being written by Joomla (everything after Error connecting to the server: comes from the HTTP request that was made). So still not something easy for us to deal with in the core platform as it means matching literal strings (and hoping they don't ever change) to figure out how to process them.

—
Reply to this email directly or view it on GitHub.

we tried to discussed this issue on: https://groups.google.com/d/msg/joomla-dev-general/krifc_thFlE/PPasTOayCtIJ

A postinstall message doesn't really help. First it may be outdated very fast, if Amazon S3 does a new cert. Second, most user don't read those. Third, in this case we have no way of doing a conditional to show it, so would have to show it to everyone, which would confuse even more users.
We could maybe write a JDoc page as a know issue and explain it there, and hopefully Google indexes it good enough so people will get there then they google the error.

JDoc page is a good start. At least if people are willing to search they can find the explanation.

Now to find someone to write a doc. It's a wiki, some takers?

peetwright: "I updated a handful of sites at various levels with various plugins and such. The weblinks update in question is the only one that kept coming up."

I had this issue for years (methinks) with Akeeba Admin Tools and Backup. Nobody else? I was in contact with Nicholas about this who said it's a hosting problem, my problem, and he would not remove his certificate checks. Of course I contacted my hoster, too, still waiting for a solution. I'm glad this discussion now sheds a bit of light on the problem.

I also like peetwright's suggestion to add a download link near the error message, if that's at all possible. Not only for this specific error, but whenever anything goes wrong with an update.

Second, most user don't read those.

Have you seen the forums lately? A lot of posts about messages that were added with 3.4.0 in there.

I stand corrected then on that part :)

I'm having the same issue on multiple sites. I'm using a Dutch host Antagonist who are using https and the certificates are up to date. "Error connecting to the server: SSL certificate problem: unable to get local issuer certificate". Manually is an option, sites update to 3.4.3 only Weblinks Extension Package gives error.

We tracked it down to an issue in the root certificate of Amazon S3. So until they fix their certs, there is not much we can do other than install the package manually (or switch to a different download place).

Google No CAPTCHA also fails for me due to the same certificate error. Anyone else, or not related and my personal problem?

Pleas eopen a new issue for that one on the main repo since it's not related to Weblinks.

I can offer a temporary download place on my cloud server with implemented SSL certificate if required. Regarding this issue, I also already had similar issues with an outdated version of cURL and Cloudflare as a proxy...

We can also use "on property" domains. Most of the joomla.org domains support SSL already and for those which don't (I can share a list of known servers and domains offline), a support ticket to hosting should resolve it. As update.joomla.org is already CDN based this would be a logical temporary solution.

What about contacting GitHub staff about the issue?

What about contacting GitHub staff about the issue?

That's already done. But since it's an Amazon S3 issue and not a GitHub one, they can't do anything themself.
And for Amazon S3 there apparently already are requests open.

I wonder if the alternative definition of updateserver (priority 2) could be helpful for such cases.

Obviously this has to be propagated to users first but maybe there's room to tweak the update workflow to pass on to other updateserver if update fails.

Honestly, I've never tried it. And it isn't the update server that actually fails; it's the URL for the actual package that's a problem. So the real question is can Joomla use an alternate <downloadurl> if one fails?

Probably this would need to be implemented to work similarly to updateserver priorities.

Good news is that there is pattern to use. update.joomla.com could be used as backup for cases like this one.
Bad news is that once it's prepared either the Amazon issue needs to be resolved to update extensions manifests or users would need to do update extensions manually.

The issue is most likely resolved anyway in 3 months. Their cert is up for renewal in 88 days.

Looks like Amazon S3 has resolved their issues with the cert. At least it's working now on my server (which was used to be broken).
Can someone with an affected server verify this?

Confirmed. Update without problems now.

Closing as this issue appears to have been resolved now.