¿Es seguro usar sslverify = true para con wp_remote_get / wp_remote_post

TL; DR: Sí, elimine esa configuración a partir de WordPress 3.7 o posterior.

En el pasado, muchas personas agregaron el parámetro sslverify = false específicamente porque su instalación de PHP no pudo verificar correctamente el certificado.

Normalmente, esto se debía a que la instalación de PHP no se había actualizado con la última copia de los certificados raíz de CA. Los certificados raíz cambian de vez en cuando, y normalmente no se nota este cambio porque ocurre en las actualizaciones normales del navegador. Bueno, cuando tiene PHP actuando como un navegador para recuperar las URL de https, también se necesitan esas actualizaciones de certificados raíz. Y la mayoría de los hosts nunca actualizan PHP, ni actualizan ninguna parte específica de él (como el archivo de certificados).

Cuando WordPress implementó la actualización automática en la versión 3.7, se determinó que era necesario actualizar las API de WordPress.org para requerir una comunicación segura. En este momento, WordPress comenzó a incluir una copia del archivo de Certificados CA Root en sí, procedente de Mozilla. Por lo tanto, desde WordPress 3.7, las funciones de la API WP_HTTP usan este archivo para realizar la verificación del certificado, y no la versión antigua o obsoleta que se incluye en la instalación de PHP.

Por lo tanto, sí, con WordPress 3.7 o posterior, es recomendable eliminar el parámetro sslverify y permitir que las funciones http realicen la verificación del certificado correspondiente. Cualquier servidor moderno que ejecute SSL con una clave firmada por una de las CA conocidas se verificará correctamente. El WP_HTTP debe tener una copia de los últimos certificados raíz, y el proyecto central actualizará ese archivo de certificados en WordPress junto con las actualizaciones normales.

Hay miles de razones que pueden permitir que una verificación SSL falle. A partir de demasiadas redirecciones a .ini files / setups o simplemente faltan certificados o subdominios. En cualquier caso, deberá buscar el motivo para eso y solucionarlo . No hay no a su alrededor.

Pero para temporalmente solucionar el problema (digamos que necesita desarrollar más su código y corregir el error de SSL más adelante), puede usar un filtro:

add_filter( 'https_ssl_verify', '__return_false' );

A medida que ejecuta esto durante una solicitud remota, debe ajustarlo en una devolución de llamada adjunta a un filtro que se activa durante dicha solicitud HTTP. Asegúrese de verificar si realmente está eliminando la verificación para el caso correcto , y asegúrese de ejecutar esto solo una vez para no dejar de tener otras solicitudes.

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

Si se trata de un complemento distribuido públicamente, es posible que desee adjuntarlo a una opción simple que el usuario puede activar o desactivar. También puede probar la solicitud verificada primero y, en caso contrario, (y si el usuario ha optado por una solicitud sin firmar), cambie a una solicitud potencialmente insegura.

  

Regla de oro:

     

No nunca realice una solicitud no segura hasta que su usuario haya aceptado   hazlo y conoce los riesgos.

WordPress puede confiar en el software del servidor subyacente (normalmente cURL) para realizar la solicitud de red. En pocas palabras porque es lo que el software es bueno y está ahí para.

En algunos servidores debido a varias razones (nunca me había molestado en verme a mí mismo) es muy típico que el software del servidor no pueda "verificar" las conexiones seguras, lo que produce dichos errores.

Entonces:

• si ese es un código privado en los servidores que controlas, debes asegurarte de que los servidores realicen las solicitudes correctamente y que esta configuración no esté deshabilitada
• Si ese es el código para la distribución pública, es probable que tampoco desees desactivarlo, pero si es lo suficientemente popular, terminará en servidores en los que se haya roto en algún momento y tendrás que admitirlo de alguna forma ( desde decirle a la gente que se espera que la configuración adecuada a la configuración para deshabilitarla para sus solicitudes, y así sucesivamente)