Я зазвичай використовую цей аргумент, щоб запобігти помилкам з wp_remote_getіwp_remote_post
array(
'sslverify' => false
)
З міркувань безпеки я хотів би встановити його true(або видалити, оскільки значення за замовчуванням відповідає дійсності).
Чи слід очікувати якихось проблем, роблячи це?
Відповіді:
TL; DR: Так, видаліть цей параметр у версії WordPress 3.7 або новішої версії.
Раніше багато людей додавали параметр sslverify = false саме тому, що їх установка PHP не змогла належним чином перевірити сертифікат.
Як правило, це було через те, що встановлення PHP не було оновлено останньою копією сертифікатів Root CA. Кореневі серти змінюються так часто, і зазвичай ви цього не помічаєте, оскільки це відбувається в звичайних оновленнях браузера. Добре, коли у вас PHP діє як браузер, щоб отримати URL-адреси https, тоді вони також потребують оновлення кореневого сертифіката. І більшість хостів ніколи не оновлює PHP, не оновлює якусь конкретну його частину (наприклад, файл сертифікатів).
Коли WordPress здійснив автоматичне оновлення у версії 3.7, було визначено, що необхідно оновити API WordPress.org, щоб вимагати безпечного зв’язку. У цей час WordPress почав включати копію самого файлу сертифікатів Root CA, отриманого від Mozilla. Отже, оскільки WordPress 3.7, функції API WP_HTTP використовують цей файл для перевірки сертифікатів, а не будь-яку стару або застарілу версію, що постачається разом із вашою установкою PHP.
Тому так, з WordPress 3.7 або пізнішої версії доцільно видалити параметр sslverify та дозволити функціям http провести належну перевірку сертифікатів. Будь-який сучасний сервер, на якому працює SSL з ключем, підписаний одним із відомих ЦА, буде перевірений належним чином. У WP_HTTP повинна бути копія останніх кореневих сертифікатів, і основний проект оновить файл сертифікатів у WordPress разом із звичайними оновленнями.
Є багато причин, які можуть призвести до того, що перевірка SSL не вдалася. Починаючи від занадто багато переадресацій до неправильних .iniфайлів / установок або просто відсутніх сертифікатів або піддоменів. У будь-якому випадку вам потрібно буде знайти причину цього і виправити це . Там немає ні шляху навколо нього.
Але щоб тимчасово вирішити цю проблему (скажімо, вам потрібно розвинути свій код і виправити помилку SSL згодом), ви можете використовувати фільтр:
add_filter( 'https_ssl_verify', '__return_false' );Коли ви це виконуєте під час віддаленого запиту, вам слід загорнути його у зворотний виклик, приєднаний до фільтра, який запускається під час такого запиту HTTP. Не забудьте перевірити, чи дійсно ви видаляєте перевірку на правильний випадок - і переконайтеся, що ви запускаєте це лише один раз, щоб не захистити інші запити.
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 );Якщо це загальнодоступний плагін, можливо, ви захочете долучити його до простого варіанту, який користувач може вмикати або вимикати. Ви також можете спробувати спершу перевірений запит, а якщо ні (і якщо користувач увімкнув непідписаний запит), перейдіть на потенційно небезпечний запит.
Практичне правило:
Ніколи не виконуйте незахищений запит, поки ваш користувач не погодиться на це і не дізнається про ризики.
WordPress може покластися на серверне програмне забезпечення, яке лежить в основі (як правило, CURL) для виконання мережевого запиту. Коротше кажучи, тому що саме це програмне забезпечення хороше і воно існує.
На деяких серверах з різних причин (я ніколи не намагався зазирнути в себе) досить типово для серверного програмного забезпечення не в змозі "перевірити" захищені з'єднання, викликаючи вказані помилки.
Так: