I normally use this argument to prevent errors with wp_remote_get and wp_remote_post
array(
'sslverify' => false
)
For security reasons I would like to set it to true (or remove it since the default is true).
Should I expect any problems by doing that?
TL;DR: Yes, remove that setting as of WordPress 3.7 or later.
In the past, many people added the sslverify=false parameter specifically because their installation of PHP was unable to properly verify the certificate.
Typically, this was because the PHP install had not been updated with the latest copy of the CA Root Certificates. The root certs change every so often, and normally you don't notice this change because it happens in normal browser updates. Well, when you have PHP acting like a browser to retrieve https urls, then it needs those root certificate updates too. And most hosts never update PHP, nor update any specific part of it (like the certificates file).
When WordPress implemented auto-updating in version 3.7, it was determined to be necessary to upgrade the WordPress.org APIs to require secure communication. At this time, WordPress began including a copy of the CA Root Certificates file itself, sourced from Mozilla. Since WordPress 3.7, therefore, the WP_HTTP API functions use this file to do certificate verification, and not whatever old or outdated version is packaged with your PHP installation.
Therefore, yes, with WordPress 3.7 or later, it is advisable to remove the sslverify parameter and allow the http functions to do proper certificate verification. Any modern server running SSL with a key signed by one of the known CAs will be verified properly. The WP_HTTP should have a copy of the latest root certificates, and the core project will update that certificates file in WordPress along with normal updates.
There are tons of reasons that can let a SSL verification fail. Starting from too many redirects to wrong .ini files/setups or simply missing certificates or sub domains. In any case, you will need to search the reason for that and fix it. There is no way around it.
But to temporarily work around that problem (let's say you need to develop your code further and fix the SSL error later on), you can use a filter:
add_filter( 'https_ssl_verify', '__return_false' );
As you are running this during a remote request, you should wrap it in a callback attached to a filter that is triggered during such a HTTP request. Make sure to check if you really are removing the verification for the correct case - and make sure that you only run this once to not unsecure other requests.
add_filter( 'http_request_args', function( $params, $url )
{
// find out if this is the request you are targeting and if not: abort
if ( 'foo' !== $params['foo'] )
return $params;
add_filter( 'https_ssl_verify', '__return_false' );
return $params;
}, 10, 2 );
If this is a publicly distributed plugin, then you might want to attach that to a simple option that the user can turn on or off. You could as well try the verified request first and if not (and if the user has opted in for a unsigned request), then switch to a potentially unsafe request.
Rule of thumb:
Do never perform an unsecure request until your user has agreed to do so and knows of the risks.
WordPress can rely on underlying server software (typically cURL) to perform network request. In a nutshell because it's what that software is good and is there for.
On some servers due to various reasons (I had never bothered looking into myself) it is quite typical for server software to not be able to "verify" secure connections, producing said errors.
So:
