joomla / joomla-cms

Home of the Joomla! Content Management System
https://www.joomla.org
GNU General Public License v2.0
4.73k stars 3.64k forks source link

Joomla! Update Component stopped working #9281

Closed richard67 closed 8 years ago

richard67 commented 8 years ago

Steps to reproduce the issue

On a 3.4.8 or earlier (because only for these there is an update path to 3.5.0 Berta 3) go to the Joomla! Update Component view, change update channel to "Testing" and click "Save & Close".

Expected result

Update is shown as available without any error messages.

Actual result

See screenshot:

screen shot 2016-03-02 at 04 38 06

Opening the XML file mentioned in the message in browser works fine, so it seems to be an SSL/TLS certificate issue.

The PHP errors shown below in the form fields for adjusting update paramenets show also that such problems are not properly handled.

System information (as much as possible)

Not relevant, only reason why 3.4.8 used and not 3.5.0 Beta X is that for 3.5.0. Beta X no updates will be offered.

richard67 commented 8 years ago

P.S.: I just see the error messages in the URL and Additional Info fields could be related to my test environment. On my life site I only have the Warning (yellow box) at the very top.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/9281.

brianteeman commented 8 years ago

When tested on live servers I had no problem When tested on localhost I had exactly the same problem

On 2 March 2016 at 10:51, Richard Fath notifications@github.com wrote:

P.S.: I just see the error messages in the URL and Additional Info fields could be related to my test environment. On my life site I only have the

Warning (yellow box) at the very top.

This comment was created with the J!Tracker Application https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/9281 https://issues.joomla.org/tracker/joomla-cms/9281.

— Reply to this email directly or view it on GitHub https://github.com/joomla/joomla-cms/issues/9281#issuecomment-191185050.

Brian Teeman Co-founder Joomla! and OpenSourceMatters Inc. http://brian.teeman.net/

richard67 commented 8 years ago

I tested on live server where also my website is located, 1and1 shared hosting. The test environment (some subdomains) I have secured with http password. My backend is "force secure", and the cert for my domain is not valid for my testing subdomains, that's maybe why I get the PHP errors there only, but for my real life site (where I get not PHP errors but still the warning about XML download) the cert is valid.

ghazal commented 8 years ago

I have posted on this issue on googlegroups since monday morning: error on xml file while trying to update to 3.4.8 - Google Groups -> https://groups.google.com/forum/#!topic/joomla-dev-general/S4wATwbEkdc

As a moderator on a joomla forum, I saw quite a fex people having this pb.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/9281.

ghazal commented 8 years ago

"a few"


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/9281.

zero-24 commented 8 years ago

@wilsonge maybe we need revert the https changes on the update servers? Or can this be realted to the update.joomla.org cert problems?

richard67 commented 8 years ago

I would guess it is the update.joomla.org cert problems.

richard67 commented 8 years ago

Symtoms are same as previous cert problems with JED.

andrepereiradasilva commented 8 years ago

Doesn't seem to exist any incomplete cert chain issues on update.joomla.org domain.

image

See https://www.ssllabs.com/ssltest/analyze.html?d=update.joomla.org&hideResults=on&latest

Symtoms are same as previous cert problems with JED.

The symtoms when your server can't connect to a https uri are always similar (e.g. no connection), but the causes of the problems can be very diverse. Also they can be client side (your server config for instance) or server side (update.joomla.org server ssl config for instance).

And they also can be Joomla side, of course.

richard67 commented 8 years ago

Hmm, am testing my stuff on shared hosting, have nothing local here, so I think I cannot go deeper with testing.

mbabker commented 8 years ago

Just out of curiosity, for the server you're hitting the could not open issue on, try plugging this URL in as a custom update stream and report the results:

https://downloads.joomla.org/component/ars/updates/files?format=xml&dummy=extension.xml

(Note: though the version reports as 3.6.0, the packages it is referencing is actually 3.4.0 because that's the latest CMS version plugged into that system right now; I just quickly changed a version number to force it to see an available update)

That'll use a different SSL certificate and possibly help ID the issue as SSL related or something else.

richard67 commented 8 years ago

Works, available update shown without any issues or warnings after having changed update channel to custom URL provided in previous comment by @mbabker .

richard67 commented 8 years ago

Applying this update on a test site works, too.

mbabker commented 8 years ago

I've dropped a ticket to hosting cross-referencing the appscdn ticket. I'm gonna be on the road today so won't be able to follow e-mail. From the looks of it @roland-d or @marijkestuivenberg could post here if there are any relevant updates on that.

richard67 commented 8 years ago

Thanks.

andrepereiradasilva commented 8 years ago

@richard67 just to check (verify peer should not be disabled), what happens if, with the normal update path, you put ...

$options[CURLOPT_SSL_VERIFYPEER] = false;

in this line https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/http/transport/curl.php#L174

ghazal commented 8 years ago

I confirm the test by @richard67 with @mbabker custom URL. It works.

richard67 commented 8 years ago

@andrepereiradasilva When I do this on a 3.5.0 Beta 3 I see as result that I am already on the current version, without any warning (was like this before, too).

When I merge that line into the file of the 3.4.8 - the file looks different but I have put this 1 line at similar place, let's say - then it still does not work.

andrepereiradasilva commented 8 years ago

ok thanks.

andrepereiradasilva commented 8 years ago

So on 3.5.0 beta 3 it works fine, only on 3.4.8 and below the problem exists, right?

ghazal commented 8 years ago

Here, it doesn't work either on the joomla 3.5 beta 3 update. (MAMP stack as localhost server)

andrepereiradasilva commented 8 years ago

from your descriptions it seems like update.joomla.org server problems as @mbabker refered.

richard67 commented 8 years ago

No, on beta 3 I cannot say if it works or not, because the updater only can see in 1st xml not mentioned in the warning that there is no update to check for in the 2nd details xml file because already on current version, and so no 2nd xml will be fetched.

richard67 commented 8 years ago

And yes I could be like @mbabker referred.

roland-d commented 8 years ago

@richard67 do you need me to report anything to Rochen? It seems @mbabker has already done so.

richard67 commented 8 years ago

@roland-d It seems he has done so and only mentioned you for reporting any news as long as he is on the road. I have no idea about ticken number and Rochen and their ticket system so I cannot watch that by myself.

andrepereiradasilva commented 8 years ago

@roland-d related: i think extensionscdn.joomla.org has problems too. Maybe should alert Rochen too.

See https://www.ssllabs.com/ssltest/analyze.html?d=extensionscdn.joomla.org&hideResults=on&latest

# openssl s_client -connect extensionscdn.joomla.org:443 -servername extensionscdn.joomla.org
CONNECTED(00000003)
depth=0 OU = GT22984067, OU = See www.rapidssl.com/resources/cps (c)15, OU = Domain Control Validated - RapidSSL(R), CN = extensionscdn.joomla.org
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = GT22984067, OU = See www.rapidssl.com/resources/cps (c)15, OU = Domain Control Validated - RapidSSL(R), CN = extensionscdn.joomla.org
verify error:num=27:certificate not trusted
verify return:1
depth=0 OU = GT22984067, OU = See www.rapidssl.com/resources/cps (c)15, OU = Domain Control Validated - RapidSSL(R), CN = extensionscdn.joomla.org
verify error:num=21:unable to verify the first certificate
verify return:1
---
// [removed for brevity]
    Verify return code: 21 (unable to verify the first certificate)
---
roland-d commented 8 years ago

@andrepereiradasilva I have updated the SSL ticket with the findings. Thanks.

andrepereiradasilva commented 8 years ago

in the SSL Labs test both servers seem ok now. See

@richard67 @ghazal do you still have the problem with update.joomla.org?

andrepereiradasilva commented 8 years ago

BTW, don't know what percentage of Joomla servers use old OS (like, for instance, CentOS 5).

image

IMHO Joomla HTTPS servers should also support some older cipher suites to fallback in case of servers with old OS. Like:

See joomla.org (https://www.ssllabs.com/ssltest/analyze.html?d=joomla.org&hideResults=on), for instance, it supports older clients.

image

richard67 commented 8 years ago

@andrepereiradasilva Just checked, problem still persists here.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/9281.

andrepereiradasilva commented 8 years ago

@richard67 what's your server system information?

ghazal commented 8 years ago

Weird, locally, behavior is different according to which AMP stack is used.

richard67 commented 8 years ago

@andrepereiradasilva Which kind you mean? The stuff shown in Joomla! backend? Or uname -a?

andrepereiradasilva commented 8 years ago

your OS/Version, openssl version (if linux or something like it)

richard67 commented 8 years ago

@andrepereiradasilva

uname -a Linux icpu1577 3.2.72-grsec-infong-15294 #1 SMP Wed Oct 21 14:57:23 CEST 2015 x86_64 GNU/Linux

openssl version OpenSSL 0.9.8o 01 Jun 2010

andrepereiradasilva commented 8 years ago

i ask this happens because downloads.joomla.org (the one that works) https configuration supports more clients than update.joomla.org.

See:

andrepereiradasilva commented 8 years ago

openssl version OpenSSL 0.9.8o 01 Jun 2010

as suspected you're using a old OpenSSL version (0.9.8) that update.joomla.org doesn't support see my previous comment (6 ou 7 comments ago - the one with images)

andrepereiradasilva commented 8 years ago

@mbabker @roland-d i think you should talk to Rochen for the joomla cdns support also old clients.

I think adding this cipher suites as fallback would be enough;

richard67 commented 8 years ago

I will wait here for further instruction by @mbabker or @roland-d on when to test again or if to close this issue.

roland-d commented 8 years ago

I have added the request by @andrepereiradasilva to the ticket at Rochen.

andrepereiradasilva commented 8 years ago

Anyway i leave this link for future reference

The following link shows which client (User Agent) supports what in the https environment. https://www.ssllabs.com/ssltest/clients.html

ghazal commented 8 years ago

If it is still of interest, I can't update to 3.4.8 with joomla component on a distant host (1&1).

richard67 commented 8 years ago

@ghazal Sure, same as me, 3.4.8 on 1&1, in my case shared host. We have to wait until Roland or someone else who follows the tickets at Rochen tells us sais that Rochen has solved it.

paulcu commented 8 years ago

Same here. Can't update from 3.4.6 to 3.4.8 on Hostgator


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/9281.

brianteeman commented 8 years ago

Upgrading level to the highest.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/9281.

andrepereiradasilva commented 8 years ago

IMHO also should be a 3.5.0 blocker, even it seems not to be a problem in joomla code itself.

brianteeman commented 8 years ago

Added release blocker status to this. No point in releasing a new version if people can't update


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/9281.

richard67 commented 8 years ago

Hmm, they still can use extension installer ... but they will not be notified in backend with the red update notifications.

roland-d commented 8 years ago

Here is the feedback from Rochen:

I'll see what our CDN provider can do here and get back to you. They may not be willing to budge on older ciphers. If that's the case we can look into alternative solutions such as simply pulling the CDN out of the equation altogether so we have more control.