Безопасно ли использовать sslverify => true для wp_remote_get/wp_remote_post

Существует множество причин, по которым проверка SSL может завершиться неудачей. Начиная от слишком большого количества редиректов, неправильных файлов/настроек .ini или просто отсутствующих сертификатов или поддоменов. В любом случае вам придется найти причину и исправить ее. Обойти это нельзя.

Но чтобы временно обойти эту проблему (например, если вам нужно продолжить разработку кода и исправить ошибку SSL позже), можно использовать фильтр:

add_filter( 'https_ssl_verify', '__return_false' );

Поскольку этот код выполняется во время удаленного запроса, его следует обернуть в колбэк, привязанный к фильтру, который срабатывает во время такого HTTP-запроса. Убедитесь, что вы отключаете проверку именно для нужного случая — и что это происходит только один раз, чтобы не сделать небезопасными другие запросы.

add_filter( 'http_request_args', function( $params, $url )
{
    // проверяем, является ли этот запрос целевым, и если нет — прерываем
    if ( 'foo' !== $params['foo'] )
         return $params;

    add_filter( 'https_ssl_verify', '__return_false' );

    return $params;
}, 10, 2 );

Если это публично распространяемый плагин, можно привязать эту настройку к простой опции, которую пользователь сможет включать или отключать. Также можно сначала попробовать проверенный запрос, а если он не сработает (и пользователь согласился на непроверенный запрос), переключиться на потенциально небезопасный вариант.

Главное правило:

Никогда не выполняйте небезопасный запрос, пока пользователь явно не согласился на это и не осознает риски.

WordPress может полагаться на базовое серверное программное обеспечение (обычно cURL) для выполнения сетевых запросов. Вкратце потому, что это то, для чего данное ПО предназначено и с чем оно хорошо справляется.

На некоторых серверах по разным причинам (я сам никогда не углублялся в этот вопрос) довольно типично, что серверное ПО не может "проверить" безопасные соединения, что приводит к указанным ошибкам.

Итак:

• если это приватный код на серверах, которые вы контролируете, вы должны убедиться, что серверы правильно выполняют запросы и эта настройка не отключена
• если это код для публичного распространения, вам, вероятно, тоже не стоит отключать эту проверку, но если ваш код станет достаточно популярным, он в какой-то момент окажется на серверах с неправильной конфигурацией, и вам придется каким-то образом поддерживать такие случаи (от объяснения пользователям, что ожидается правильная конфигурация, до предоставления настроек для отключения проверки для ваших запросов и так далее)