È sicuro utilizzare sslverify => true con wp_remote_get/wp_remote_post
Normalmente uso questo argomento per prevenire errori con wp_remote_get
e wp_remote_post
array(
'sslverify' => false
)
Per motivi di sicurezza vorrei impostarlo a true
(o rimuoverlo dato che il valore predefinito è true).
Dovrei aspettarmi problemi facendo questo?

TL;DR: Sì, rimuovi quell'impostazione a partire da WordPress 3.7 o versioni successive.
In passato, molte persone aggiungevano il parametro sslverifica=false specificamente perché la loro installazione di PHP non era in grado di verificare correttamente il certificato.
Tipicamente, ciò accadeva perché l'installazione di PHP non era stata aggiornata con l'ultima copia dei Certificati Root CA. I certificati root cambiano di tanto in tanto, e normalmente non te ne accorgi perché questo cambiamento avviene durante i normali aggiornamenti del browser. Beh, quando PHP agisce come un browser per recuperare URL https, allora ha bisogno anche di quegli aggiornamenti dei certificati root. E la maggior parte degli host non aggiorna mai PHP, né aggiorna alcuna sua parte specifica (come il file dei certificati).
Quando WordPress ha implementato l'aggiornamento automatico nella versione 3.7, è stato ritenuto necessario aggiornare le API di WordPress.org per richiedere una comunicazione sicura. In quel momento, WordPress ha iniziato a includere una copia del file dei Certificati Root CA, proveniente da Mozilla. A partire da WordPress 3.7, quindi, le funzioni dell'API WP_HTTP utilizzano questo file per effettuare la verifica dei certificati, e non la versione vecchia o obsoleta fornita con la tua installazione di PHP.
Pertanto, sì, con WordPress 3.7 o versioni successive, è consigliabile rimuovere il parametro sslverify e consentire alle funzioni http di effettuare una corretta verifica dei certificati. Qualsiasi server moderno che esegue SSL con una chiave firmata da uno dei CA noti sarà verificato correttamente. WP_HTTP dovrebbe avere una copia degli ultimi certificati root, e il progetto core aggiornerà quel file dei certificati in WordPress insieme ai normali aggiornamenti.

Ci sono moltissime ragioni che possono causare il fallimento della verifica SSL. A partire da troppi reindirizzamenti fino a file/configurazioni .ini
errati o semplicemente certificati o sottodomini mancanti. In ogni caso, dovrai cercare la causa del problema e risolverlo. Non c'è nessun modo per aggirarlo.
Ma per aggirare temporaneamente il problema (supponiamo che tu debba sviluppare ulteriormente il tuo codice e risolvere l'errore SSL in un secondo momento), puoi utilizzare un filtro:
add_filter( 'https_ssl_verify', '__return_false' );
Dato che stai eseguendo questo codice durante una richiesta remota, dovresti racchiuderlo in una callback collegata a un filtro che viene attivato durante tale richiesta HTTP. Assicurati di verificare se stai effettivamente rimuovendo la verifica per il caso corretto - e assicurati di eseguirlo solo una volta per non compromettere la sicurezza di altre richieste.
add_filter( 'http_request_args', function( $params, $url )
{
// verifica se questa è la richiesta che stai cercando e se non lo è: interrompi
if ( 'foo' !== $params['foo'] )
return $params;
add_filter( 'https_ssl_verify', '__return_false' );
return $params;
}, 10, 2 );
Se si tratta di un plugin distribuito pubblicamente, potresti voler collegare questa funzionalità a un'opzione semplice che l'utente può attivare o disattivare. Potresti anche provare prima la richiesta verificata e, in caso di fallimento (e se l'utente ha acconsentito a una richiesta non firmata), passare a una richiesta potenzialmente non sicura.
Regola generale:
Non eseguire mai una richiesta non sicura finché l'utente non ha acconsentito esplicitamente ed è consapevole dei rischi.

WordPress può fare affidamento su software server sottostante (tipicamente cURL) per eseguire richieste di rete. In sintesi, perché è ciò per cui quel software è fatto ed è lì.
Su alcuni server, per varie ragioni (non mi sono mai preoccupato di approfondire personalmente), è abbastanza comune che il software server non sia in grado di "verificare" le connessioni sicure, producendo i suddetti errori.
Quindi:
- se si tratta di codice privato su server che controlli, dovresti assicurarti che i server effettuino le richieste correttamente e che questa impostazione non sia disabilitata
- se si tratta di codice per distribuzione pubblica, probabilmente non vorrai disabilitarlo neanche lì, ma se diventa abbastanza popolare finirà prima o poi su server dove è rotto e dovrai supportarlo in qualche forma (dal dire alle persone che ci si aspetta una configurazione corretta, al fornire un'impostazione per disabilitarlo per le tue richieste, e così via)
