ssl - Perl, LWP "certificate verify failed" with paypal.com -
not 100% sure perl issue, seems be. have ipn script connects paypal verify transactions. working fine until yesterday, when installed lwp::protocol::https. since then, it's been failing error:
can't connect 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 @ /usr/local/share/perl5/lwp/protocol/http.pm line 47. running get https://www.paypal.com bash (which uses lwp) yields same error message. otoh, running get https://www.gmail.com successful. running openssl s_client -host paypal.com -port 443 returns (among other things) verify return code: 0 (ok). curl "https://www.paypal.com/cgi-bin/webscr?cmd=_notify-validate" receives response paypal. seem perl-specific.
module versions:
lwp 6.13 lwp::protocol::https 6.06 io::socket::ssl 2.015 mozilla::ca 20141217 (note: i've tried script both using mozilla::ca , without it... results have been same) please let me know if there other relevant modules. perl version 5.10.1. server os rhel 6.
mozilla::ca 20141217 (note: i've tried script both using mozilla::ca , without it... results have been same)
in short: don't know "without it" means rhel6 please try again mozilla::ca 20130114 or "older ca-bundle" linked http://curl.haxx.se/docs/caextract.html.
details: certificate chain www.paypal.com
[0] www.paypal.com [1] symantec class 3 ev ssl ca - g2 [2] verisign class 3 public primary certification authority - g5 the last certificate in chain signed 1024 certificate
/c=us/o=verisign, inc./ou=class 3 public primary certification authority since 1024 bit certificates removed mozilla end of last year not find them in current mozilla::ca longer. browsers don't need old certificate because create trust chain based on certificates [0] , [1] because use built-in certificate instead of certificate [2] send server.
while newer built-in certificate included in mozilla::ca not used because of long-standing bug in how openssl validates certificates: try validate longest chain , not check if shorter chain possible.
for more details problem see
- the original bug report against openssl 2012
- a more recent description of problem, not affects perl python, ruby, curl, wget... - i.e. uses openssl: https://stackoverflow.com/a/27826829/3081018
the problem can resolved using flag x509_v_flag_trusted_first introduced openssl 1.02 (released 4 month ago , not in rhel yet) or using newer , not yet released version of openssl fixed problem (see https://rt.openssl.org/ticket/display.html?id=3637&user=guest&pass=guest).
the problem can worked around having older 1024 bit ca certificates still available, i.e either using older mozilla::ca or ca bundle or using system ca store includes these older ca. see also:
- a current bug report against io::socket::ssl use x509_v_flag_trusted_first default (if available). flag gets set 2.016 (not yet released) needs version of net::ssleay exports flag (not yet released) , openssl 1.02 (not included in rhel).
- a pull request against lwp use default ca on system instead of mozilla::ca. save problem too. note debian/ubuntu have similar patch included. don't know version of lwp shipped rhel.
Comments
Post a Comment