Eu normalmente uso esse argumento para evitar erros com wp_remote_getewp_remote_post
array(
'sslverify' => false
)Por motivos de segurança, gostaria de defini-lo como true(ou removê-lo, pois o padrão é verdadeiro).
Devo esperar algum problema ao fazer isso?
Respostas:
TL; DR: Sim, remova essa configuração a partir do WordPress 3.7 ou posterior.
No passado, muitas pessoas adicionaram o parâmetro sslverify = false especificamente porque sua instalação do PHP não conseguiu verificar corretamente o certificado.
Normalmente, isso ocorreu porque a instalação do PHP não havia sido atualizada com a cópia mais recente dos Certificados Raiz da CA. O certificado raiz muda de vez em quando, e normalmente você não percebe essa alteração porque ocorre 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 de certificado raiz. E a maioria dos hosts nunca atualiza o PHP, nem atualiza qualquer parte específica (como o arquivo de certificados).
Quando o WordPress implementou a atualização automática na versão 3.7, foi determinado que era necessário atualizar as APIs do WordPress.org para exigir comunicação segura. Nesse momento, o WordPress começou a incluir uma cópia do próprio arquivo CA Root Certificates, originário da Mozilla. Desde o WordPress 3.7, portanto, as funções da API WP_HTTP usam esse arquivo para verificar o certificado, e não qualquer versão antiga ou desatualizada incluída na instalação do PHP.
Portanto, sim, com o WordPress 3.7 ou posterior, é recomendável remover o parâmetro sslverify e permitir que as funções http façam a verificação adequada do certificado. Qualquer servidor moderno executando 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 juntamente com as atualizações normais.
Existem vários motivos que podem permitir uma falha na verificação SSL. Começando de muitos redirecionamentos para .iniarquivos / configurações incorretos ou simplesmente faltando certificados ou subdomínios. De qualquer forma, você precisará pesquisar o motivo e corrigi-lo . Não há maneira de contornar isso.
Mas, para solucionar temporariamente esse problema (digamos que você precise desenvolver mais seu código e corrigir o erro SSL posteriormente), você pode usar um filtro:
add_filter( 'https_ssl_verify', '__return_false' );Como você está executando isso durante uma solicitação remota, envolva-a em um retorno de chamada anexado a um filtro que é acionado durante uma solicitação HTTP. Verifique se você realmente está removendo a verificação para o caso correto - e execute-o apenas uma vez para não garantir 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 este for um plug-in distribuído publicamente, convém anexá-lo a uma opção simples que o usuário possa 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 prática:
Você não executar uma solicitação não segura até que o usuário tenha concordado em fazê-lo e sabe dos riscos.
O WordPress pode confiar no software do servidor subjacente (normalmente cURL) para executar a solicitação de rede. Em poucas palavras, porque é para isso que o software é bom e existe.
Em alguns servidores, por várias razões (nunca me preocupei em me examinar), é bastante comum que o software do servidor não consiga "verificar" as conexões seguras, produzindo os erros.
Então: