Menos de una respuesta, pero solo una lista de cosas directamente de mi experiencia con él, tal vez has pasado por alto algo.
Depuración de la solicitud y sus resultados
Sin profundizar demasiado en el proceso de actualización, pero la API HTTP de WP usa la WP_HTTPclase. También ofrece algo agradable: un gancho de depuración.
do_action( 'http_api_debug', $response, 'response', $class, $args, $url );
Donde $responsetambién puede haber un WP_Errorobjeto que quizás te diga más.
Nota: a partir de una breve prueba, este filtro parece funcionar solo (por alguna razón) si lo coloca tan cerca de donde realmente está haciendo la solicitud. Entonces, tal vez deba llamarlo desde una devolución de llamada en uno de los siguientes filtros.
WP_HTTP Argumentos de clase
Los argumentos de las clases en sí son filtrables, pero algunos pueden restablecerse mediante los métodos internos de nuevo a lo que WP supone que es necesario.
apply_filters( 'http_request_args', $r, $url );
Uno de los argumentos es ssl_verify, que es cierto por defecto (pero para mí causa problemas masivos al actualizar desde, por ejemplo, GitHub). Editar: después de depurar una solicitud de prueba, encontré otro argumento configurado para verificar si SSL está configurado como true. Se llama sslverify(sin separar el guión bajo). No tengo idea de dónde entró esto en el juego, si realmente está en uso o abandonado y si tienes la oportunidad de influir en su valor. Lo encontré usando el 'http_api_debug'filtro.
Completamente personalizado
También puede "simplemente" anular todas las partes internas e ir con una configuración personalizada. Hay un filtro para eso.
apply_filters( 'pre_http_request', false, $r, $url );
El primer argumento debe establecerse en verdadero. Entonces puedes interactuar con los argumentos dentro $ry el resultado de parse_url( $url );.
Apoderado
Otra cosa que podría funcionar podría ser ejecutar todo a través de un Proxy personalizado. Esto necesita algunas configuraciones en su wp-config.php. Nunca he intentado esto antes, pero revisé las constantes hace un tiempo y resumí algunos ejemplos que deberían funcionar e incluí algunos comentarios en caso de que algún día lo necesite. Tienes que definir WP_PROXY_HOSTy WP_PROXY_PORTcomo min. ajuste. De lo contrario, nada funcionará y simplemente pasará por alto su proxy.
# HTTP Proxies
# Used for e.g. in Intranets
# Fixes Feeds as well
# Defines the proxy adresse.
define( 'WP_PROXY_HOST', '127.0.84.1' );
# Defines the proxy port.
define( 'WP_PROXY_PORT', '8080' );
# Defines the proxy username.
define( 'WP_PROXY_USERNAME', 'my_user_name' );
# Defines the proxy password.
define( 'WP_PROXY_PASSWORD', 'my_password' );
# Allows you to define some adresses which
# shouldn't be passed through a proxy.
define( 'WP_PROXY_BYPASS_HOSTS', 'localhost, www.example.com' );
EDITAR
La WP_HTTPclase normalmente actúa como clase base (se extenderá para diferentes escenarios). Los extienden WP_HTTP_*clases son Fsockopen, Streams, Curl, Proxy, Cookie, Encoding. Si 'http_api_debug'conecta una devolución de llamada a la acción, el tercer argumento le dirá qué clase se utilizó para su solicitud.
Dentro de la WP_HTTP_curlclase, encontrarás el request()método. Este método ofrece dos filtros para interceptar el comportamiento SSL: uno para solicitudes locales 'https_local_ssl_verify'y otro para solicitudes remotas 'https_ssl_verify'. WP probablemente definirá localcomo localhosty de qué obtienes a cambio get_option( 'siteurl' );.
Entonces, lo que debería hacer es intentar lo siguiente justo antes de hacer esa solicitud (o de una devolución de llamada que esté conectada a la solicitud más cercana:
add_filter( 'https_ssl_verify', '__return_true' );
# Local requests should be checked with something like
# 'localhost' === $_SERVER['HTTP_HOST'] or similar
# add_filter( 'https_local_ssl_verify', '__return_true' );
Nota al margen: en la mayoría de los casos WP_HTTP_curlse utilizará para manejar Proxies.
