Support

Please ask your host or the Joomla! forum. The update is performed by Joomla! itself. We don't have an updater of our own anymore.

If you're wondering, yes, we USED to have an updater of our own. One which was very stable, rock solid and much more efficient. But people were calling us incompetent for not using Joomla!'s own updater which displays an update reminder in the control panel. So yes, we switched to Joomla!'s own extension updater. So far we've seen the following problems which are OUTSIDE our code and can't possibly fix them:

- Update information getting stuck, showing obsolete versions of the component as the latest
- Update download failing with mysterious error codes (like yours) which seem to be related to hosting issues regarding the verification of our SSL certificate (which we had to upgrade to an SHA256 signed one because Google demanded so – long story)
- Update time outs leading to partial updates

No problem! The ticket will remain open for 15 days since your last reply.

What they did note was that restore points has been implemented and it apparently overwrites the Joomla extension installer.

No, it doesn't. The chain of events is:
- Joomla! downloads the update XML file
- Joomla! notifies you for the update
- You tell Joomla! to install the update
- Joomla! downloads the package*
- Joomla! extracts the package*
- The System Restore Point plugin redirects you to Akeeba Backup which takes a short extension-only backup (a.k.a. System Restore Point)
- Akeeba Backup sends you back to Joomla!'s extensions installer
- Joomla! installs the package
- Joomla! cleans up the temporary directory

The items with a star are part of the System Restore Points plugin but are NOT implemented with code in Akeeba Backup. We simply ask Joomla! to handle the download and extraction.

I did disable this and it did not change the result. I still get the same error. I'm thinking of uninstalling and then reinstalling.

That's because the System Restore Points plugin has nothing to do with your problem.

Within approximately 8 seconds of doing a Google search on the error I found this page https://www.tbs-certificates.co.uk/FAQ/en/old_openssl_sha256.html which explains the error message abundantly to any system administrator:

The software you are using might be compiled with a version too old of OpenSSL that does not take certificates signed with sha256WithRSAEncryption into account.



It requires at least OpenSSL 0.9.8o for a total management of SHA256. OpenSSl 0.9.7m only assures a partial management, for server mode only.

Now, please let me translate geek-talk to what is my closest approximation to plain English.

AkeebaBackup.com uses HTTPS to protect your privacy. Our Professional versions' updates are delivered, of course, through HTTPS. HTTPS itself is plain HTTP over SSL. SSL is, let's put it simply, an encryption layer. It uses something called public key cryptography.

The difference of public key cryptography when compared to regular cryptography is that the sender and the recipient don't need to share a secret key (pass-phrase) to ensure privacy of their communication. Instead, the sender has a private key and they recipient is sent a public key. The sender encrypts his data with the private key and the recipient unlocks it with the public key. Conversely, when the recipient encrypts (locks) something with the public key, only the recipient can unlock it with his private key.

You might have observed a problem here. The public key. How the heck can you be sure that the public key AkeebaBackup.com sent you is the real deal and not a forgery by a hacker or *cough* NSA *cough*. The bright minds implementing public key cryptography have a solution and it's called key signing. It's basically a trust system. Our public key is signed by a company called Thawte. Thawte is one of the very few companies who can do that. Their public key comes pre-installed in your browser and shipped with software such as Joomla!. In Joomla!'s case, Thawte's (and other key signing companies') public key is located in a file called cacert.pem. The signed public key is called an "SSL certificate".

When your browser or Joomla! contacts our site they first need to verify that our "SSL certificate" is valid. This means that they read our public key and its signature and verify that the signature is authentic. If the signature is authentic it means that Thawte trusts us, i.e. they have been sent a copy of my passport, our documents of incorporation, verified the existence of my company and yours truly against the government databases and interviewed me to make sure I'm not a crook pretending to be Nicholas (and yes, this has all happened). Since your browser and Joomla! trust Thawte they trust the SSL certificate on AkeebaBackup.com which is signed by Thawte. It's exactly the same way government-issued ID cards and passports work: you trust that the issuing government vouches for the identity of the person bearing the ID card in a way that makes forgery extremely difficult.

Are you still with me? Because now comes the confusing part. The inherent trust comes from the "way that makes forgery extremely difficult". When we're talking about SSL certificates this means that the signing method is tamper-proof. There are several cryptographic signing algorithms. The most commonly used one is SHA-1 and the newest one is SHA-256 (also known as SHA-2). SHA-1 was the golden standard until some very clever applied mathematicians figured a way to create forgeries back in 2010. That elaborate forgery was very theoretical back in 2010 as it required a crapload of computing power. By late 2014 it was possible for nation state actors (*cough* NSA *cough*) to create such forgeries with reasonable cost. The prediction is that by 2017 every man and his dog will be able to do that for a few meager hundreds of dollars.

Google and Mozilla –undoubtedly shaken by the revelations of a certain ex-spook subcontractor (*cough* Snowden *cough*)– decided that the risk of SHA-1 signatures was too high and they couldn't really call them a "way that makes forgery extremely difficult" without cringing like having bitten a really sour lemon. So they decreed that any site caught using an SHA-1 signed SSL certificate would be treated as if their SSL certificate was garbage. This forced all of us to issue new certificates, signed with the super secure for the foreseeable, not so distant future SHA-256 algorithm.

Which takes us back to Joomla!. Joomla! uses PHP to communicate with HTTPS-secured web servers like ours. PHP relies on another piece of software to do the signature checking. That piece of software is called the OpenSSL library. Sadly, older versions of the OpenSSL library were quite dumb when it came to SHA-256 signatures and didn't know what to make of them. So they were throwing an error. The exact error you are now receiving.

So, the real problem is that Rochen compiled PHP with an old version of OpenSSL (version 0.9.7m or earlier). They need to upgrade OpenSSL to 0.9.8o or later and then recompile PHP. It will only take them a day. Maybe three, as their CEO –and I believe their lead engineer as well– are attending Joomla! Day UK this weekend. It's really that easy. Please ask Rochen to talk to an engineer and give them a URL to this ticket. I'm sure someone will go "no way... oh, we do have an old OpenSSL on that box, dang it" upon reading this ticket. Also let them know that if they have any question they can get in touch with me any time. Chris Adams has my contact details and I will be most happy to help them solve this issue, even during the weekend.

You're welcome, Duane!