Perl, LWP «проверка сертификата не удалась» с paypal.com

Question

Не на 100% уверен, что это проблема с Perl, но это похоже. У меня есть сценарий IPN, который соединяется с PayPal для проверки транзакций. Он работал нормально до вчерашнего дня, когда я установил LWP :: Protocol :: https. С тех пор он был сбой с ошибкой:

Can't connect to www.paypal.com:443 (certificate verify failed) 

LWP::Protocol::https::Socket: SSL connect attempt failed error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/local/share/perl5/LWP/Protocol/http.pm line 47. 

Запуск GET https://www.paypal.com от Баш (который использует LWP) дает такое же сообщение об ошибке. OTOH, работает GET https://www.gmail.com успешно. Бег openssl s_client -host paypal.com -port 443 возвращается (между прочим) Verify return code: 0 (ok). curl "https://www.paypal.com/cgi-bin/webscr?cmd=_notify-validate" успешно получает ответ от PayPal. Так что это похоже на Perl-специфику.

модуль версии:

LWP 6.13 
LWP::Protocol::https 6.06 
IO::Socket::SSL 2.015 
Mozilla::CA 20141217 (note: I've tried the script both using Mozilla::CA and without it... results have been the same) 

Пожалуйста, дайте мне знать, если есть другие соответствующие модули. Версия Perl - 5.10.1. OS Сервер RHEL 6.

Answer 1

Mozilla::CA 20141217 (note: I've tried the script both using Mozilla::CA and without it... results have been the same)

Короче: я не знаю, что «без него» означает, что для RHEL6 но, пожалуйста, попробуйте еще раз с Mozilla :: CA 20130114 или с «старой ча-расслоению» связаны от http://curl.haxx.se/docs/caextract.html.

Детали: Сертификат цепи вы получите от www.paypal.com

[0] www.paypal.com 
[1] Symantec Class 3 EV SSL CA - G2 
[2] VeriSign Class 3 Public Primary Certification Authority - G5 

Последний сертификат в цепочке подписан 1024 сертификата

/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority 

С 1024 битных сертификатов где удалена Mozilla в конце прошлого года вы больше не найдете их в текущем Mozilla :: CA. Но браузеру не нужен старый сертификат, поскольку создать цепочку доверия на основе сертификатов [0] и [1] уже потому, что они используют встроенный сертификат вместо сертификата [2], отправляемого сервером.

Хотя этот более новый встроенный сертификат также включен в Mozilla :: CA, он не будет использоваться из-за давней ошибки в том, как OpenSSL проверяет сертификаты: он всегда будет пытаться проверять самую длинную цепочку и не проверять, возможна более короткая цепь.

Для получения более подробной информации об этой проблеме см

• the original bug report against OpenSSL с 2012
• более недавнее описание проблемы, которая не только влияет на Perl, но и Python, Ruby, локон, Wget ... - т.е. все, что использует OpenSSL: https://stackoverflow.com/a/27826829/3081018

проблема может быть решена с помощью флага X509_V_FLAG_TRUSTED_FIRST, который был введен с OpenSSL 1.02 (выпущен 4 месяца назад и, вероятно, не в RHEL еще) или с помощью эв в новой версии и еще не выпущенной версии OpenSSL, где они, наконец, исправили проблему (см. https://rt.openssl.org/Ticket/Display.html?id=3637&user=guest&pass=guest).

Проблема может быть решена благодаря наличию более старых 1024-битных CA-сертификатов, то есть с использованием более старого пакета Mozilla :: CA или CA или с использованием хранилища CA системы, который обычно включает в себя эти старые CA.Смотрите также:

• current bug report против IO :: Socket :: SSL использовать X509_V_FLAG_TRUSTED_FIRST по умолчанию (если таковые имеются). Этот флаг устанавливается с 2.016 (еще не выпущен), но ему нужна версия Net :: SSLeay, которая экспортирует этот флаг (еще не выпущенный) и OpenSSL 1.02 (не входит в RHEL).
• A pull request against LWP использовать CA по умолчанию вместо системы Mozilla :: CA. Это, вероятно, спасет проблему и для вас. Обратите внимание, что в Debian/Ubuntu включен аналогичный патч. Я не знаю о версии LWP, поставляемой с RHEL.