I have several joomla sites to update. Joomla 3.9.25 to 3.10.2 and PHP 7.4.24 or 7.4.21. But all with the same problem that appeared on October 1st when I tried to update. This happens for all my sites hosted by Siteground, but also on localhost on my iMac (Mamp Pro), but not on an OVH server on which I also have a Joomla site. But for the OVH site, when I transfer it on my local server, bang, the problem happens! So, this seems to be partly related to the server configuration, but I really don't know what to do about it. Maybe you will have some clues to help me find the solution?
Joomla Update component and Regulalabs Extension Manager are both concerned.
Some extensions are not affected. This is the case for example Akeeba Backup, JCE, sh404SEF, Joomla languages packages… for which Joomla gets the data.
Joomla Update component : error for several extensions, but not all of them: "Update: Could not open update site."
Regularlabs Extension Manager (v 7.5.1, manually updated): "Could not retrieve data from the Regular Labs website. Please try again later."
Siteground tech support was no help at this time, but someone did on the Facebook SiteGround Users Group! The problem seems to be related to that:
. And the Siteground server would be involved (with another host, OVH, it works like a charm). But my Siteground server is not the only one involved, because the updates for the Joomla core are working (language packages, optional components), as well as several other third party extensions that I often use.
During the update process (via curl), when the servers communicate with each other, this Joomla file, containing many certificates, is apparently queried:
. If the recovery of the update data fails, perhaps it is because some servers are unable to use this file as expected (because it contains an outdated certificate).
A very complicated problem (I'm not an expert 🙁 at the wrong time (just as I start a batch of updates)!
It appears that modifying a single Joomla file solve the problem. I tested on several sites (live sites and localhost) and it works well, I found back a normal behavior and I could update my extensions.
Solution consists in removing the DST Root CA X3 certificate from the cacert.pem file (/libraries/src/Http/Transport/cacert.pem)(obiously, make a backup of the file before).
Probably this "hack" will not be necessary any more in a few days and probably we could use it only during the time we need to update extensions.
I've had this same problem and had been having trouble finding a copy of the DST Root CA X3, so that I knew which part to remove from the cacert.pem - they're not exactly commented in the file and there's heaps of them.