@westiefan

Your link show me a 403 error

Oh, dear, we have a 403
ACCESS FORBIDDEN
Please try one of the following pages:
Home Page 

So it is expected that Joomla can't dowonload it. (or i missed somthing?)

This comment was created with the J!Tracker Application at http://issues.joomla.org/.

@zero-24 You got a 403 because he changed his download ID after realising he's posted it in public. If he hadn't changed it I'd have to kill his subscription ;)

Regarding this issue, it occurs whenever the server doesn't have a server-wide cacerts.pem (root certificate authority cache) installed or when it's not visible to PHP. Right now Joomla! does ship a cacert.pem which is used by JHttpTransportCurl. I believe that his server doesn't have the PHP cURL module enabled, therefore Joomla! resorts to using either the JHttpTransportStream wrapper. However, Joomla! doesn't tell fopen() to use the cacert.pem file as $context only has the HTTP options and none of the SSL options. See the related php.net thread. We would need to change line 128 from
$context = stream_context_create(array('http' => $options));
to

$context = stream_context_create(array(
    'http' => $options,
    'ssl' => array(
        'verify_peer'   => true,
        'cafile'        => __DIR__ . '/cacert.pem',
        'verify_depth'  => 5,
    )
));

in the file libraries/joomla/http/transport/stream.php

@westiefan Funny how your support request that ended with "sorry, that's a Joomla! bug" comes back to me to solve. :) Since I don't have an affected server to test this solution, would you mind giving my proposed fix a shot and post back here whether it worked? Thank you in advance!

hehe yes you are right, thanks :D @nikosdion

Hi @nikosdion,

Thank you, and yes, after our dialogue I had a feeling that you would end up getting involved. It has taken me a while to double check the server setup and to get myself setup with a GitHub account so that I could get this posted.

Ref the Download ID code, I didn't change it, so thank you to whoever it was that changed it for me, as it never occured to me that it would cause an issue. However, you missed the link at the end of the post, so I have now also changed that link (Nicholas, if you would feel happier changing my download ID as a result of this, please do send me a new one to replace the potentially compromised one).

Anyway, sorry but I tried your fix on my site, but unfortunately it did not work. One thing that I did notice in your code was that there was what appeared (to me at least) to be an extra comma after the line "'verify_depth' => 5" in the array, so after it failed on testing "as is", I removed the comma and tried again, but it made no difference, any other ideas?

Ref the PHP cURL module, yes it is enabled, along with the other suggestions that you made in your support forum, but please go to http://www.yourwebservicesltd.co.uk/phpinfo.php to see full server config settings (I will leave the phpinfo.php file uploaded until this is resolved), as it should confirm that all of the settings are correct on the server as previously discussed in your forum.

John

It was me that removed the download id
On 4 Sep 2014 22:14, "westiefan" notifications@github.com wrote:

Hi @nikosdion https://github.com/nikosdion,

Thank you, and yes, after our dialogue I had a feeling that you would end
up getting involved. It has taken me a while to double check the server
setup and to get myself setup with a GitHub account so that I could get
this posted.

Ref the Download ID code, I didn't change it, so thank you to whoever it
was that changed it for me, as it never occured to me that it would cause
an issue. However, you missed the link at the end of the post, so I have
now also changed that link (Nicholas, if you would feel happier changing my
download ID as a result of this, please do send me a new one to replace the
potentially compromised one).

Anyway, sorry but I tried your fix on my site, but unfortunately it did
not work. One thing that I did notice in your code was that there was what
appeared (to me at least) to be an extra comma after the line
"'verify_depth' => 5", so after it failed on testing "as is", I removed the
comma and tried again, but it made no difference.

Ref the PHP cURL module, yes it is enabled, along with the other
suggestions that you made in your support forum, but please go to
http://www.yourwebservicesltd.co.uk/phpinfo.php to see full server config
settings (I will leave the phpinfo.php file uploaded until this is
resolved), as it should confirm that all of the settings are correct on the
server as previously discussed in your forum.

John

—
Reply to this email directly or view it on GitHub
#4218 (comment).

@brianteeman
Thank you. You missed the other link at the end, but I have addressed that now, I will bear it in mind for the future though.

@nikosdion,

Further to my earlier reply, I just had a quick look at the PHP reference that you included, and I can see where the additional comma came from, and perhaps this could explain why it didn't work.

After the line "'verify_depth' => 5,", in the PHP reference there is another entry in the array that is missing from your fix, so perhaps there needs to be another element in order to fix it. In the PHP reference there is an additional line "'CN_match' => 'secure.example.com'", so it could be that there needs to be an additional element in the array to reflect this.

In addition, there also appears to be 2 additional lines of code that also appear to be relevant, though how and if you need them in this context is beyond my coding knowledge.

@westiefan I have to give you quite a few No's in this answer :(

No, the extra comma isn't a problem.

No, the CN_match is not required. When present, it instructs PHP to match the canonical name in the certificate. We don't need that.

No, the stream transport won't even load on your site since you have curl enabled.

No, this is actually not the issue I spotted in Joomla!, it's a problem with your host, as I suspected at first. Since you have curl enabled the JHttpTransportCurl loads on your site and this already works perfectly with HTTPS sites. However, your host DOES block communications with external servers as I said in my first reply to you. You know what? Dump them already. Move your site to a decent host. It's a far better use of your money and everybody's time (including yours).

Finally, no, I didn't change your Download ID before replying to this issue. I had changed your Download ID a week ago after you posted it in a public ticket. I had told you so (in the public ticket I closed), I thought you were aware :)

@nikosdion,

Ok, no worries.

Based on your comments ref the download ID, I had not realised that you had changed the ID after posting in the Akeeba forum, and I went over your replies and cannot see any mention of this, but maybe I just missed it.

Ref changing my host, they are very good from a Joomla perspective so I would be very reluctant to change them as I have almost 200 sites hosted with them, and changing would be a major headache, and besides which, as noted below, as your fix worked with my new download ID it is not neccessary, as I will just need to update the ID for my supported sites.

However, in the light of the revalation that you changed the download ID previously, when I tested your fix, I was still using the old download ID, so this would explain why the fix didn't work.

The good news is that now that I replaced the Download ID with a valid ID, I tried your fix again, as written, and it is now working, so well done you.

As I can now confirm that this fix worked, will it be incorporated into the next security update release?

As I have so many sites I do not want to manually update them all, particularly if it will be updated in the core next time around, so in the meantime I can continue manual updates until the fix is included.

Well done Nicholas, your help is much appreciated as always.

Good news, bad news:

Oh, great! So we found the problem :)

Let me recap: cURL was not enabled in your server, that's why Joomla!
picked up the "stream" interface which uses fopen(). The problem was what I
originally imagined it would be: since Joomla! didn't provide the location
to cacert.pem, retreiving an HTTPS URL failed. So my fix worked after all!
Yay!

So, you don't need to change hosts which is a good thing. We found the
problem in Joomla! and fixed it. We have a successful test (you). I would
propose that we set it to RTC as it's a trivial issue which doesn't need
two testers. Anyone from the PLT around to do that? Please? :)

You PR it and we'll get it merged (unless it's already there and I just haven't seen it)

@mbabker Created PR gh-4232 Thank you!

@nikosdion,

Thank you Nicholas, sorry I didn't notice the change of download ID when I did the initial test of your fix, but alls well that ends well.

Thanks to you and @mbabker for moving this towards incorporating in the next security update, I look forward to seeing my one click updates working again for the Akkeba Backup Pro (once I have changed the ID on the relevant sites :)

Doh! Brain fart. I'll do the PR shortly.