É seguro usar o sslverify = true com wp_remote_get / wp_remote_post

TL; DR: Sim, remova essa configuração no WordPress 3.7 ou posterior.

No passado, muitas pessoas adicionavam o parâmetro sslverify = false especificamente porque a instalação do PHP não era capaz de verificar corretamente o certificado.

Normalmente, isso ocorre porque a instalação do PHP não foi atualizada com a cópia mais recente dos Certificados Raiz da CA. Os certificados de raiz mudam de vez em quando, e normalmente você não percebe essa mudança porque isso acontece nas atualizações normais do navegador. Bem, quando você tem o PHP agindo como um navegador para recuperar URLs https, ele também precisa dessas atualizações do certificado raiz. E a maioria dos hosts nunca atualiza o PHP, nem atualiza qualquer parte específica dele (como o arquivo de certificados).

Quando o WordPress implementou a atualização automática na versão 3.7, foi determinado que seria necessário atualizar as APIs do WordPress.org para exigir comunicação segura. No momento, o WordPress começou a incluir uma cópia do próprio arquivo de certificados raiz da CA, originado da Mozilla. Desde o WordPress 3.7, portanto, as funções da API WP_HTTP usam este arquivo para fazer a verificação do certificado, e não qualquer versão antiga ou desatualizada é empacotada com a sua instalação do PHP.

Portanto, sim, com o WordPress 3.7 ou posterior, é aconselhável remover o parâmetro sslverify e permitir que as funções http executem a verificação adequada do certificado. Qualquer servidor moderno que execute SSL com uma chave assinada por uma das CAs conhecidas será verificado corretamente. O WP_HTTP deve ter uma cópia dos certificados raiz mais recentes, e o projeto principal atualizará esse arquivo de certificados no WordPress junto com as atualizações normais.

Existem vários motivos pelos quais uma verificação de SSL pode falhar. Começando de muitos redirecionamentos para .ini files / setups errados ou simplesmente perdendo certificados ou sub-domínios. Em qualquer caso, você precisará pesquisar o motivo para isso e corrigi-lo . Não há nenhum meio de contorno.

Mas para resolver temporariamente esse problema (digamos que você precise desenvolver mais o seu código e corrigir o erro SSL mais tarde), você pode usar um filtro:

add_filter( 'https_ssl_verify', '__return_false' );

Como você está executando isso durante uma solicitação remota, você deve envolvê-lo em um retorno de chamada anexado a um filtro que é acionado durante uma solicitação HTTP. Certifique-se de verificar se você realmente está removendo a verificação para o caso correto - e certifique-se de executar apenas uma vez para não desabilitar outras solicitações.

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 );

Se esse for um plug-in distribuído publicamente, convém anexá-lo a uma opção simples que o usuário pode ativar ou desativar. Você também pode tentar a solicitação verificada primeiro e, se não (e se o usuário tiver optado por uma solicitação não assinada), alterne para uma solicitação potencialmente insegura.

  

Regra geral:

     

Não faça nunca executar uma solicitação não segura até que o usuário tenha concordado com   faça isso e saiba dos riscos.

O WordPress pode contar com o software de servidor subjacente (normalmente cURL) para executar solicitações de rede. Em suma, porque é o que esse software é bom e está lá para.

Em alguns servidores, devido a vários motivos (nunca me preocupei em investigar a mim mesmo), é bastante comum que o software de servidor não consiga "verificar" conexões seguras, produzindo esses erros.

Então:

• se for um código privado nos servidores que você controla, verifique se os servidores estão fazendo solicitações corretamente e se essa configuração não está desativada
• se esse for o código para distribuição pública, você provavelmente não desejará desativá-lo também, mas se ele for popular o suficiente, ele terminará em servidores em que ele está quebrado em algum momento e você terá que suportar isso de alguma forma ( de dizer às pessoas que a configuração adequada deve fornecer a configuração para desativá-lo para suas solicitações, e assim por diante)