Support » Fixing WordPress » Error: WordPress could not establish a secure connection to WordPress.org

  • Resolved peterbb

    (@peterbb)


    I’ve installed WordPress 4.8.2 on OpenBSD 6.2. I’ve installed and loaded the php-curl package, since someone on the internet claimed it is needed.

    The page is up and running—seems to work fine; I can upload media, edit and save themes in Appearance -> Editor (so that should mean it has write access, something I’ve also checked manually), create posts, the site looks beautiful when viewed, etc.

    The problem I’m trying to solve, is to change the site language. I’ve gone to Settings -> General, but the Site Language option is not there. However, by enabling WP_DEBUG I can see the following error message:

    Warning: An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in /htdocs/<redacted>/wp-admin/includes/translation-install.php on line 65

    The same error also appears other pages, such as Plugins -> Add New.

    From the shell on the server, I can curl both http://api.wordpress.org/translations/ and https://api.wordpress.org/translations, and receive a HTTP response—so there is nothing on the server blocking access.

    I’ve tried the following, with no difference in outcome:

    • Disable firewall.
    • I’ve enabled caching dns, and I’ve also tried to add entries to /etc/hosts, in order to speed up DNS-lookup.
    • In—for instance wp-admin/includes/translation-install.php—I’ve changed timeout to 3000 at line 44 in my file.

    I’ve rebooted the server between these efforts. The outcome is exactly as before.

    Could anyone offer any help? Thanks in advance.

Viewing 15 replies - 1 through 15 (of 16 total)
  • Moderator Steve Stern

    (@sterndata)

    Support Volunteer

    The “secure connection” error usually comes if you’re not running the latest version of OpenSSL.

    Thanks for the lead!

    OpenBSD uses LibreSSL by default, not OpenSSL, so that might be why. openssl version gives LibreSSL 2.6.3, but I guess that doesn’t tell us too much.

    I’ll try to dig further into it now, but if anyone has some more details, then please tell me!

    Edit: Simply installing openssl-1.0.2l and restarting did not change anything—as expected, I guess. I guess I’ll need to either make it use openssl (recompile php? :/) or figure out where the php-code fails.

    • This reply was modified 8 months, 1 week ago by  peterbb.

    I have managed to narrow the problem down to the combination of cURL and ipv6. From # curl -6 google.com ,which prints curl: (7) Couldn't connect to server, and # ping6 -c 1 google.com, which print

    PING google.com (2a00:1450:400e:803::200e): 56 data bytes
    ping6: sendmsg: No route to host

    we can see that ipv6 is not working on the machine. I wonder if this is related to
    Ramnode — OpenBSD IPv6 Issue (my OpenBSD server is running on a Ramnode KVM).

    I tried to configure curl to use IPv4, by adding curl_setopt($this->handle, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4); in wp-includes/Requests/Transport/cURL.php after the handle is created in the constructor, but this had no effect. Both CURLOPT_IPRESOLVE and CURL_IPRESOLVE_V4 are defined, so I would have thought it would work. 🙁

    • This reply was modified 8 months, 1 week ago by  peterbb.
    Moderator Steve Stern

    (@sterndata)

    Support Volunteer

    hmmmm… I tend to forget about IPV6 as we don’t have it at home and 99.999% of all connections to my own server use IPv4.

    peterbb

    (@peterbb)

    Update: IPv6 is now working on the server, but there are still problems. To see that IPv6 works, curl -6 google.com spits out some html from google.

    Now, both curl https://api.wordpress.org/translations/core/1.0/ and curl http://api.wordpress.org/translations/core/1.0/ spits out all the supported languages, but curl -6 https://api.wordpress.org/translations/core/1.0/ gives curl: (6) Could not resolve host: api.wordpress.org (it also happens with http). This makes sense, since there is no AAAA record for api.wordpress.org as far as I can see.

    Edit: This is intentional, cf. https://meta.trac.wordpress.org/ticket/3090

    But it’s not like I *want* to use IPv6, so why is curl trying to use it anyway?

    • This reply was modified 8 months ago by  peterbb.
    • This reply was modified 8 months ago by  peterbb.
    peterbb

    (@peterbb)

    Done! Finally everything is working.

    Added the line curl_setopt($this->handle, CURLOPT_RESOLVE, array("api.wordpress.org:80:66.155.40.187", "api.wordpress.org:443:66.155.40.187")); in wp-includes/Requests/Transport/cURL.php. What an absurd problem.

    @peterbb
    Thanks a lot!
    I met the same trouble and now I fix it with your method!

    
    	/**
    	 * Constructor
    	 */
    	public function __construct() {
    		$curl = curl_version();
    		$this->version = $curl['version_number'];
    		$this->handle = curl_init();
    
    		//SaFly.ORG Adaption
    		curl_setopt($this->handle, CURLOPT_RESOLVE, array("api.wordpress.org:80:66.155.40.187", "api.wordpress.org:443:66.155.40.187", "downloads.wordpress.org:80:66.155.40.203", "downloads.wordpress.org:443:66.155.40.203"));
    
    		curl_setopt($this->handle, CURLOPT_HEADER, false);
    		curl_setopt($this->handle, CURLOPT_RETURNTRANSFER, 1);
    		if ($this->version >= self::CURL_7_10_5) {
    			curl_setopt($this->handle, CURLOPT_ENCODING, '');
    		}
    		if (defined('CURLOPT_PROTOCOLS')) {
    			curl_setopt($this->handle, CURLOPT_PROTOCOLS, CURLPROTO_HTTP | CURLPROTO_HTTPS);
    		}
    		if (defined('CURLOPT_REDIR_PROTOCOLS')) {
    			curl_setopt($this->handle, CURLOPT_REDIR_PROTOCOLS, CURLPROTO_HTTP | CURLPROTO_HTTPS);
    		}
    	}
    
    

    Let me make it more detailed 🙂

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    You should probably use a more future proof way, rather than altering the core files.

    Something like this should do the trick (untested):

    
    add_action('http_api_curl', 'custom_curl_resolve', 10, 3 );
    function custom_curl_resolve( $handle, $r, $url ) {
    	curl_setopt($handle, CURLOPT_RESOLVE, array(
    		"api.wordpress.org:80:66.155.40.187", 
    		"api.wordpress.org:443:66.155.40.187", 
    		"downloads.wordpress.org:80:66.155.40.203", 
    		"downloads.wordpress.org:443:66.155.40.203")
    	);
    }
    

    You could add on to this, if you like, and add logic to check the $url to see if it matches one of those and then you’d only be adding the ones you need.

    The http_api_curl happens before the request to curl_exec is fired, and curl is already init’d by that point, so much of the rest of the code that sets options you have could be added there if those are needed.

    This code could be contained in a plugin or in a mu-plugin and would survive upgrades.

    Edit: Note that the http_api_curl hook is there for backwards compatibility. If you want to use the same hook but specific to the Requests system, that hook is requests-curl.before_send.

    I also had this issue
    and fixed in the SaFly
    because I hope this issue will be raise to the DevTeam and they will fix it.

    For info, I also wasn’t able to curl -6 which is make sense because IPv6 is disabled on my machine 🙂

    Anyway @otto42, I didn’t understood where tp put you’re code to test it ?

    • This reply was modified 6 months, 1 week ago by  jodumont.

    Same issue here on OpenBSD. Extremely frustrating and I agree with the OP – absurd.

    And it is still not working for me.

    I tried the OP solution which also worked for SaFly AND the moderator’s excellent suggestion to make that a mu-plugin (which, by the way goes into a directory that is not created by WordPress at install time) – and nothing has worked. It turns out that the problem (on OpenBSD) is that they have disabled IPv6 by default. Henning Brauer in the OpenBSD Journal:

    Automagically adding an inet6 address just because an interface comes up is ridiculous and actually a security risk, since your machine is suddenly reachable over it (to some extent), which might not even be clear to the person taking the interface up. And it goes further, that automagic inet6 address even causes problems in some setups, e. g. with bridges. So we eventually decided to turn off v6 by default, which is how it should have been from the beginning – actively adding an inet6 address, manually or by running rtsol for autoconfig, turned it on and everything magically worked right. Without the implicit attack vector. So that is actually invisible to almost all that use inet6 – only those just using link-local, without any “real” inet6 address, had to adapt slightly. Pleasantly even the die-hard inet6 lovers in our group agreed with that move.

    Clearly, I need to enable IPv6 for WordPress – but only for the use of installing themes, installing plugins, and getting news. Oddly, WordPress.org does not even use IPv6 so they must be converting it to IPV4 on their end, but forcing us to use it. This makes no sense.

    In any case, the solution here appears to be to open IPv6 (making the site more vulnerable) and then making the mu-plugin described above and then checking the system to see if WordPress.org has changed their IP address for those two servers from time to time or when things die (the current IP address from nsloookup does not match the above IPs).

    Please moderators, make a plea to fix this.

    I have developed a plug-in named SaFly Curl Patch which can solve the resolving problems getting the ip of WordPress automatically and will survive upgrades.
    It aims at solving the error about WordPress connection and I will continue to update it.
    Hope that you enjoy it~

    @jeffbrower @jodumont @otto42 @peterbb @sterndata

    == Installation ==
    The easy way:
    1. Go to the Plugins Menu in WordPress
    2. Search for “SaFly Curl Patch”
    3. Click “Install”
    The not so easy way:
    1. Upload the ml-slider folder to the /wp-content/plugins/ directory
    2. Activate the plug-in through the ‘Plugins’ menu in WordPress

    I get this error constantly on OSX so I have little control over what outdated version of Open SSL Apple gives me.

    My God, what is this?

    I’ve got my Pi nicely running IPv6, WP installed fine, and now I’m days trying to solve a problem on my side that is caused by wordpress.org (and wordpress.com).

    I recently tried the solutions handed by @safly and @otto42, but to no avail.
    I have now asked the WordPress.org Systems team to take care that a ticket is opened to have WordPress communicate with WordPress.org and WordPress.com (and any other site that is only IPv4) through IPv4 only.

    Sadly, I don’t have the knowledge and experience to make a fix myself.

Viewing 15 replies - 1 through 15 (of 16 total)
  • The topic ‘Error: WordPress could not establish a secure connection to WordPress.org’ is closed to new replies.