简体   繁体   English

使用paypal.com的Perl,LWP“证书验证失败”

[英]Perl, LWP “certificate verify failed” with paypal.com

Not 100% sure this is a Perl issue, but it seems to be. 不是100%肯定这是一个Perl问题,但似乎是。 I have an IPN script that connects with PayPal to verify transactions. 我有一个与PayPal连接的IPN脚本来验证交易。 It was working fine until yesterday, when I installed LWP::Protocol::https. 它工作正常,直到昨天,我安装了LWP :: Protocol :: https。 Since then, it's been failing with the error: 从那时起,它一直没有出现错误:

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.

Running GET https://www.paypal.com from bash (which uses LWP) yields the same error message. 从bash(使用LWP)运行GET https://www.paypal.com产生相同的错误消息。 OTOH, running GET https://www.gmail.com is successful. OTOH,运行GET https://www.gmail.com是成功的。 Running openssl s_client -host paypal.com -port 443 returns (among other things) Verify return code: 0 (ok) . 运行openssl s_client -host paypal.com -port 443返回(除其他外) Verify return code: 0 (ok) curl "https://www.paypal.com/cgi-bin/webscr?cmd=_notify-validate" successfully receives a response from PayPal. curl "https://www.paypal.com/cgi-bin/webscr?cmd=_notify-validate"成功收到PayPal的回复。 So it does seem to be Perl-specific. 所以它似乎确实是Perl特有的。

Module versions: 模块版本:

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)

Please let me know if there are other relevant modules. 如果有其他相关模块,请告诉我。 Perl version is 5.10.1. Perl版本是5.10.1。 Server OS is RHEL 6. 服务器操作系统是RHEL 6。

Mozilla::CA 20141217 (note: I've tried the script both using Mozilla::CA and without it... results have been the same) Mozilla :: CA 20141217(注意:我已经尝试过使用Mozilla :: CA而没有它的脚本......结果是一样的)

In short: I don't know what "without it" means for RHEL6 but please try again with Mozilla::CA 20130114 or with the "older ca-bundle" linked from http://curl.haxx.se/docs/caextract.html . 简而言之:我不知道“没有它”对于RHEL6意味着什么,但请再次尝试使用Mozilla :: CA 20130114或使用http://curl.haxx.se/docs/caextract链接的“旧版ca-bundle” .html

Details: The certificate chain you get from www.paypal.com 详细信息:您从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 the chain is signed by the 1024 certificate 链中的最后一个证书由1024证书签名

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

Since 1024 bit certificates where removed by Mozilla end of last year you will not find them in the current Mozilla::CA any longer. 由于去年年底Mozilla删除了1024位证书,因此您不会再在当前的Mozilla :: CA中找到它们。 But browsers don't need the old certificate because the create the trust chain based on certificates [0] and [1] already because they use a built-in certificate instead of the certificate [2] send by the server. 但浏览器不需要旧证书,因为基于证书[0]和[1]创建信任链已经因为它们使用内置证书而不是服务器发送的证书[2]。

While this newer built-in certificate is also included in Mozilla::CA it will not be used because of a long-standing bug in how OpenSSL validates certificates: it will always try to validate the longest chain and not check if a shorter chain is possible. 虽然这个较新的内置证书也包含在Mozilla :: CA中,但由于OpenSSL如何验证证书存在长期存在的错误,因此它将不会被使用:它将始终尝试验证最长的链,而不是检查较短的链是否是可能。

For more details about this problem see 有关此问题的详细信息,请参阅

The problem can be resolved by using the flag X509_V_FLAG_TRUSTED_FIRST which was introduced with OpenSSL 1.02 (released 4 month ago and probably not in RHEL yet) or by using an even newer and not yet released version of OpenSSL where they finally fixed the problem (see https://rt.openssl.org/Ticket/Display.html?id=3637&user=guest&pass=guest ). 这个问题可以通过使用OpenSSL 1.02(4个月前发布,可能还没有在RHEL中)引入的标志X509_V_FLAG_TRUSTED_FIRST解决,或者使用更新的尚未发布的OpenSSL版本来解决问题(参见https) ://rt.openssl.org/Ticket/Display.html?id = 3637&user = guest&pass = guest )。

The problem can be worked around by having the older 1024 bit CA certificates still available, ie either using an older Mozilla::CA or CA bundle or using the system CA store which usually includes these older CA. 通过使旧的1024位CA证书仍然可用,即使用较旧的Mozilla :: CA或CA捆绑包或使用通常包括这些旧CA的系统CA存储,可以解决该问题。 See also: 也可以看看:

  • A current bug report against IO::Socket::SSL to use the X509_V_FLAG_TRUSTED_FIRST by default (if available). 针对IO :: Socket :: SSL的当前错误报告 ,默认情况下使用X509_V_FLAG_TRUSTED_FIRST(如果可用)。 This flag gets set with 2.016 (not yet released) but needs a version of Net::SSLeay which exports this flag (not yet released) and OpenSSL 1.02 (not included in RHEL). 此标志设置为2.016(尚未发布)但需要一个Net :: SSLeay版本,它导出此标志(尚未发布)和OpenSSL 1.02(未包含在RHEL中)。
  • A pull request against LWP to use the default CA on the system instead of Mozilla::CA. 针对LWP拉取请求,以使用系统上的默认CA而不是Mozilla :: CA. This would probably save the problem for you too. 这也可能为您解决问题。 Note that Debian/Ubuntu have a similar patch included. 请注意,Debian / Ubuntu包含了类似的补丁。 I don't know about the version of LWP shipped with RHEL. 我不知道RHEL附带的LWP版本。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM