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

	/**
	 * 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);
		}
	}

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 get this error constantly on OSX so I have little control over what outdated version of Open SSL Apple gives me.