Closed richard67 closed 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.
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/
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.
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.
"a few"
@wilsonge maybe we need revert the https changes on the update servers? Or can this be realted to the update.joomla.org cert problems?
I would guess it is the update.joomla.org cert problems.
Symtoms are same as previous cert problems with JED.
Doesn't seem to exist any incomplete cert chain issues on update.joomla.org domain.
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.
Hmm, am testing my stuff on shared hosting, have nothing local here, so I think I cannot go deeper with testing.
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.
Works, available update shown without any issues or warnings after having changed update channel to custom URL provided in previous comment by @mbabker .
Applying this update on a test site works, too.
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.
Thanks.
@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
I confirm the test by @richard67 with @mbabker custom URL. It works.
@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.
ok thanks.
So on 3.5.0 beta 3 it works fine, only on 3.4.8 and below the problem exists, right?
Here, it doesn't work either on the joomla 3.5 beta 3 update. (MAMP stack as localhost server)
from your descriptions it seems like update.joomla.org server problems as @mbabker refered.
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.
And yes I could be like @mbabker referred.
@richard67 do you need me to report anything to Rochen? It seems @mbabker has already done so.
@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.
@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)
---
@andrepereiradasilva I have updated the SSL ticket with the findings. Thanks.
in the SSL Labs test both servers seem ok now. See
@richard67 @ghazal do you still have the problem with update.joomla.org?
BTW, don't know what percentage of Joomla servers use old OS (like, for instance, CentOS 5).
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.
@andrepereiradasilva Just checked, problem still persists here.
@richard67 what's your server system information?
Weird, locally, behavior is different according to which AMP stack is used.
@andrepereiradasilva Which kind you mean? The stuff shown in Joomla! backend? Or uname -a?
your OS/Version, openssl version (if linux or something like it)
@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
i ask this happens because downloads.joomla.org (the one that works) https configuration supports more clients than update.joomla.org.
See:
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)
@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;
I will wait here for further instruction by @mbabker or @roland-d on when to test again or if to close this issue.
I have added the request by @andrepereiradasilva to the ticket at Rochen.
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
If it is still of interest, I can't update to 3.4.8 with joomla component on a distant host (1&1).
@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.
Same here. Can't update from 3.4.6 to 3.4.8 on Hostgator
Upgrading level to the highest.
IMHO also should be a 3.5.0 blocker, even it seems not to be a problem in joomla code itself.
Added release blocker status to this. No point in releasing a new version if people can't update
Hmm, they still can use extension installer ... but they will not be notified in backend with the red update notifications.
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.
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:
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.