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 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

Popular posts from this blog

node.js - Using Node without global install -

How to access a php class file from PHPFox framework into javascript code written in simple HTML file? -

java - Null response to php query in android, even though php works properly -