не удалось подключиться или не удалось проверить сертификат на LWP HTTPS GET

Вчера я разместил эту проблему на Perl Monks, но она сработала для всех, кто ее пробовал (см. perlmonks.org/?node_id=909968). Однако я использовал другой URL-адрес, надеясь упростить проблему.

Я пытаюсь подключиться к api.betfair.com через HTTPS, и у них есть действующий сертификат, который я проверил в своем браузере. У меня Ubuntu и две версии Perl. Системная 5.10.0 работает, а 5.14.0 установленная через perlbrew не работает. Код:

use LWP::UserAgent; 
use strict;
use warnings;

#$ENV{HTTPS_CA_FILE} = "/usr/share/ca-certificates/cacert.org/cacert.org.crt";

my $ua  = LWP::UserAgent->new; 
my $req = HTTP::Request->new(GET => 'https://api.betfair.com');
my $res = $ua->request($req);

print $res->headers_as_string;
print $res->content;

Запустив это в системе Perl 5.10.0, все работает нормально, и я получаю:

Date: Fri, 17 Jun 2011 08:33:04 GMT
Accept-Ranges: bytes
ETag: W/"0-1307353787000"
Content-Length: 0
Content-Type: text/html
Last-Modified: Mon, 06 Jun 2011 09:49:47 GMT
Client-Date: Fri, 17 Jun 2011 08:33:04 GMT
Client-Peer: 84.20.200.10:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
Client-SSL-Cert-Subject: /C=GB/ST=London/L=London/O=The Sporting Exchange Ltd/OU=IS/OU=Terms of use at www.verisign.com/rpa (c)05/CN=*.betfair.com
Client-SSL-Cipher: RC4-MD5
Set-Cookie: NSC_mc-80-qvcbqj.efgbvmu=ffffffff09208c5545525d5f4f58455e445a4a4229a0;expires=Fri, 17-Jun-2011 20:33:05 GMT;path=/;httponly

Запустив его под Perl 5.14.0, я получаю: Тип содержимого: text/plain Дата клиента: Пт, 17 июня 2011 г., 08:34:30 GMT Предупреждение клиента: Внутренний ответ Не удается подключиться к api.betfair. ком:443

Если я раскомментирую настройку HTTPS_CA_FILE и перезапущу в 5.14.0, я получу:

Content-Type: text/plain
Client-Date: Fri, 17 Jun 2011 08:35:09 GMT
Client-Warning: Internal response
Can't connect to api.betfair.com:443 (certificate verify failed)

LWP::Protocol::https::Socket: SSL connect attempt failed with unknown errorerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /home/martin/perl5/perlbrew/perls/perl-5.14.0/lib/site_perl/5.14.0/LWP/Protocol/http.pm line 51.

У меня установлен Mozilla::CA версии 20110409. Mozilla::CA::SSL_ca_file() возвращает "/home/martin/perl5/perlbrew/perls/perl-5.14.0/lib/site_perl/5.14.0/Mozilla/CA /cacert.pem", и он существует и доступен мне для чтения. Я использую LWP 6.02 в Perl 5.14.0 и 5.836 в Perl 5.10.0. Я читал, что настройка HTTPS_DEBUG=1 должна выводить некоторую отладочную информацию, но она делает это (для меня) только при использовании Perl 5.10.0, а не 5.14.0.

Я ни в коем случае не гуру SSL, но я попробовал некоторые вещи, которые нашел, и они только еще больше меня запутали:

openssl verify -verbose -CAfile /home/martin/perl5/perlbrew/perls/perl-5.14.0/lib/site_perl/5.14.0/Mozilla/CA/cacert.pem < /dev/null
unable to load certificate
10888:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: TRUSTED CERTIFICATE

openssl s_client -CAfile /usr/local/share/perl/5.10.0/Mozilla/CA/cacert.pem -connect api.betfair.com:443 < /dev/null
CONNECTED(00000003)
depth=1 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=GB/ST=London/L=London/O=The Sporting Exchange Ltd/OU=IS/OU=Terms of use at www.verisign.com/rpa (c)05/CN=*.betfair.com
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
---
Server certificate
-----BEGIN CERTIFICATE-----
certificate snipped
sg==
-----END CERTIFICATE-----
subject=/C=GB/ST=London/L=London/O=The Sporting Exchange Ltd/OU=IS/OU=Terms of use at www.verisign.com/rpa (c)05/CN=*.betfair.com
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
---
No client certificate CA names sent
---
SSL handshake has read 3068 bytes and written 303 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-MD5
    Session-ID: 81802384A47AF45D2D809A2D10041A4E0B4B4DD821507569216A199ED467B207
    Session-ID-ctx: 
    Master-Key: 50DEC11CD2FA57E9BFA95B0156905D2717A79F333A2028FCCCB0F1C32A6B35202A958CEF24D3D2332A00CDCD158B40FB
    Key-Arg   : None
    Start Time: 1308304989
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
DONE

ОБНОВЛЕНИЕ: я думал, что это из-за того, что у меня был установлен PERL_UNICODE=SAL, но его отключение не решает проблему.

ОБНОВЛЕНИЕ: версии: Linux ubuntu 10.10, кодовое имя maverick openssl 0.9.80 (я полагаю, что в моем дистрибутиве ubuntu последняя версия


person bohica    schedule 17.06.2011    source источник
comment
Бьюсь об заклад, у вас нет промежуточного сертификата, как в stackoverflow.com/q/5639803#5654982   -  person daxim    schedule 17.06.2011
comment
Для записи установите для переменной среды PERL_LWP_SSL_VERIFY_HOSTNAME значение 0 проходит проверку сертификата. Не рекомендуется, конечно, но пригодится в экстренной ситуации.   -  person Tim Bunce    schedule 28.10.2014
comment
Согласен, Тим, так и должно быть, но в моей системе это не работало и не работает до сих пор. Также выполнение $ua-›ssl_opts(verify_hostname =› 0) не работает в моей системе. Я все еще пытаюсь выяснить, почему.   -  person bohica    schedule 04.11.2014


Ответы (1)


$ openssl s_client -connect api.betfair.com:443 < /dev/null > api.betfair.com.pem
$ openssl x509 -in api.betfair.com.pem -issuer_hash
eb99629b

Что ж, скажем так, это тот же дурацкий промежуточный сертификат 0xeb99629b, который я видел раньше у других людей, см. комментарий выше подробности и как получить.

Из любопытства, какую версию OpenSSL и ca-сертификатов вы используете? Какая у вас версия системы/вендор?

person daxim    schedule 17.06.2011
comment
обновлена ​​​​операция с версией openssl и системой. Не знаю, как найти версию ca-сертификатов. Была такая же проблема с facebook martin-evans.me.uk/node/95 около месяца назад, но решил это по-другому. Спасибо, Даксим - я знал, что ты будешь диагностировать это - чуть не спросил тебя прямо. - person bohica; 17.06.2011
comment
openssl s_client -CAfile cert.pm -connect api.betfair.com:443 ‹ /dev/null теперь работает. хотя Perl не работает - все еще пытаюсь. - person bohica; 17.06.2011
comment
HTTPS_CA_FILE=cert.pm perl ca2.pl, где ca2.pl — это perl в op, не работает таким же образом. - person bohica; 17.06.2011
comment
Скачать сертификат, на который вы указали. sudo cp cert.pm /etc/ssl/certs/Verisign_Class_3_Secure_Server_CA_G2.pem; судо c_rehash; perl ca2.pl по-прежнему не работает - та же проблема. символическая ссылка в /etc/ssl/certs: 4d241d64.0 -> Verisign_Class_3_Secure_Server_CA_G2.pem - person bohica; 17.06.2011
comment
Мне не удалось воспроизвести вашу проблему на новой виртуальной машине Ubuntu 10.10, извините. -- dpkg --status openssl # Version=0.9.8o-1ubuntu4.4 dpkg --status ca-certificates Version=20090814 -- Поскольку вы заставили его работать с s_client, теперь вы можете просто указать стек SSL LWP в директории системных сертификатов: HTTPS_CA_DIR=/etc/ssl/certs perl... - person daxim; 17.06.2011
comment
Указание системных сертификатов работает - спасибо и проголосовал. Хотя это действительно неприятная проблема. Хотел бы я решить, где может быть проблема, чтобы я мог сообщить об этом. - person bohica; 17.06.2011
comment
Проблема заключается во многих вещах одновременно (по крайней мере, культура Perl, стремящаяся угодить всем, и PKI через центры сертификации - полная ерунда), и ее нельзя решить с помощью простого отчета. Посетите YAPC::EU, я представлю доклад. - person daxim; 17.06.2011