radishconcepts/WordPress-GitHub-Plugin-Updater

CA certificate verify failed

Closed this issue · 8 comments

WordPress throws an error when I try to autoupdate:
Download failed. SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

The problem (and solution) is discussed here: http://unitstep.net/blog/2009/05/05/using-curl-in-php-to-access-https-ssltls-protected-sites/ but I believe the curl options would need to be set inside WordPress core files.

Is there another work around for this?

Hey there,

Thanks for reporting the issue. Interestingly enough, the client for whom I built this class originally had this issue as well on his server.
From my understanding of the issue, it is server/environment specific. I have implemented the following fix for my client. I do believe that this fix could (with some hackery) pose a security threat, but it's a little bit over my head to be 100% honest. Here's the fix: https://gist.github.com/1260379, you can implement it as a standalone plugin or as part of your theme/plugin.

Suggestions welcome for this.
Cheers

That works great, thanks!

It would make the WordPress update curl less secure by setting it to trust all certificates ... but as far as I can tell there is no way to give WordPress a list of trusted certificates, so I don't see another option.

Yeah exactly, that's why I'd rather not include it in the class by default.

On 2011-10-03, at 5:05 PM, Paul Kilmurray wrote:

That works great, thanks!

It would make the WordPress update curl less secure by setting it to trust all certificates ... but as far as I can tell there is no way to give WordPress a list of trusted certificates, so I don't see another option.

Reply to this email directly or view it on GitHub:
#2 (comment)

I think this can be fixed by adding "'sslverify' => false" to the wp_remote_get args, like:

wp_remote_get($this->config['api_url'], array( 'sslverify' => false );

Hey @pmichael thanks for the new and better solution. I can confirm that your solution works, which is great. I will opt to not include this in the core class for now as it could still be seen as a security issue and the initial problem only affects certain installations of WordPress. That being said, I am open to being convinced as to why this should be included in the class.

Also, if anyone does run into this problem, they should definitely use @pmichael's solution.

You're welcome. You could add the option to the config array, setting 'sslverify' => true by default.

I ended up playing around with this after realizing that the sslverify option still caused updates to fail because ZIP downloads occur outside of the plugin's HTTP calls.

After monitoring default WordPress updates, I found they normally use HTTP:

These connections aren't verifying with a Certificate Authority, and they are not encrypted. Running Github updates over HTTPS without sslverify causes them to also not check with a Certificate Authority, but they're still encrypted. So, overall, HTTPS without sslverify is still more secure than normal WordPress update requests.

I agree that it's unwise to disable sslverify across the board, because there may be other connections that need it. Using the code below, sslverify can be disabled for Git plugin updates only. I think using this as the default setting will provide safe and stable updates for everyone:

In WPGitHubUpdater::__construct()
// Disable HTTP SSL Certificate Check for Git URLs only
add_filter( 'http_request_args', array($this, 'disable_git_ssl_verify'), 10, 2 );
In WPGitHubUpdater
/**
 * Disable SSL only for git repo URLs, but no other HTTP requests
 *  Allows SSL to be disabled for zips that are downloadeds outside plugin scope
 *
 * @return array $args http_request_args
 */
public function disable_git_ssl_verify($args, $url) {
    if ( in_array($url, $this->config) ) {
        $args['sslverify'] = false; 
    }else {
        return $args;
    }
}

@pdclark I sort of did something like this, but it was only for the ZIP URLs, since the current codebase only misses it at that point.

#20