我的服务器突然不再接收来自 Paypal 的 IPN 请求，工作了多年
Posted
技术标签:
【中文标题】我的服务器突然不再接收来自 Paypal 的 IPN 请求，工作了多年【英文标题】：My server is suddenly not receiving IPN requests from Paypal any more, worked for years 【发布时间】：2021-11-28 19:56:01 【问题描述】：我已经使用 IPN 多年：我使用经典的 Paypal 按钮发起购买，然后 Paypal 将 IPN 发送到我的网络服务器，以便我可以记录付款并向客户发送电子邮件。
但自 2021 年 10 月 4 日起，Paypal 无法再向我发送 IPN。
“即时付款通知 (IPN) 历史记录”将此后的所有 IPN 显示为失败或待处理。
但是，如果我从浏览器调用 IPN URL，我的服务器会很好地响应请求。我的服务器（带有 Apache 2 的 Debian 10）在过去一周没有进行任何配置更改或软件包更新，尤其是在它仍然收到 IPN 的时间（10 月 3 日）之后。
在那个日期（10 月 3 日），我能找到的唯一变化是自动更新 Let's Encrypt SSL 证书，这种情况在之前发生过很多次，而不会对 IPN 造成任何此类问题。从那以后，我重新创建了 Let's Encrypt 证书，即使是专门针对提供给 Paypal 的域的证书（在该服务器上的多个域之间共享证书之前），但没有任何改进。
什么有效
从 curl 或网络浏览器调用 URL (https://paypal-api.tempel.org/)。我的 CGI 脚本被调用，Apache access.log 显示 GET 请求。
什么不起作用
使用IPN Simulator，指定相同的URL - 然后模拟器页面显示
IPN 未发送，握手未验证。查看您的信息
在顶部，我在 Apache access.log 中看到 no 请求
发生了什么变化？
我检查了我的防火墙（我有一段时间没有更改），甚至禁用它，但无济于事。
为什么 Paypal 会突然联系不上我的服务器？
我怀疑它与 SSL 证书有关，因为它的更新日期是我能找到的唯一日期关系，而且由于 Paypal 不接受 SSL 证书也可能导致它甚至不会发出 GET或向我的服务器发送 POST 请求，因此没有关于它的日志条目。
我用模拟器做测试对吗？我怎么才能知道为什么 Paypal 不执行“握手”？
SSL 证书异常
尽管 certbot 表示 SSL 证书是最新的，但我还是从 openssl 获得了该域的以下输出：
% openssl s_client -connect paypal-api.tempel.org:443 -showcerts -CApath /etc/ssl/certs/
CONNECTED(00000005)
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
---
Certificate chain
0 s:/CN=git.tempel.org
i:/C=US/O=Let's Encrypt/CN=R3
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=git.tempel.org
issuer=/C=US/O=Let's Encrypt/CN=R3
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 4574 bytes and written 281 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-CHACHA20-POLY1305
Session-ID: 523AEDD29014010191C7B3DD16F4DC7179B8D91372C3063CEF8D6AD2ED7B800E
Session-ID-ctx:
Master-Key: 36D105B8EAD319DA6B8D2EA30484FC6676F2A2D64CA0EE8889B16396ECA71178FE5154638DCE1E9AF051D8D2FA44472E
Start Time: 1633776598
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
closed
为什么顶部显示“证书已过期”，即使最后没问题？会不会是这个问题？
更奇怪的是，当我给 IPN 模拟器另一个我的域时，它也使用 Let's Encrypt，例如www.tempel.org，模拟器昨天回复了一个肯定的结果，但今天，它给出了同样的“握手”错误。另外，openssl 昨天在 IPN 模拟器仍然接受它时已经给出了相同的“证书已过期”错误。
所以，这一切似乎都与 Let's Encrypt 的证书有关。但是除了购买不同的 SSL 证书之外，我该如何解决这个问题？
或者这只是一些奇怪的缓存问题？当我在 Safari 中打开 https://paypal-api.tempel.org/ 并检查其证书信息时，它并不表示任何过期的证书。这是怎么回事？
与 X3 根证书最近到期有关？
我有一种预感，这与expiry of one of Let's Encrypt's root certificate on Sept 30, 2021 有关。我上面显示的openssl 命令确实提到了X3 证书。
但是，我仍然不清楚如何解决此问题。我了解 SO 文章中有关禁用过时的 X3 证书的说明，但还不明白该怎么做。可能使用certbot 强制更新证书。但即便如此，Simulator 仍然不满意，而且openssl cmd 始终提到 X3 根目录。
更新了证书
在阅读 here 关于修复 X3 到期问题后，我通过强制 X1 根来更新我的证书（h1.tempel.org 是同一服务器上的另一个域）：
certbot renew --cert-name h1.tempel.org --preferred-chain "ISRG Root X1" --force-renewal
然后重新启动 Apache (apachectl graceful)。
奇怪的是，从那时起，当我将https://h1.tempel.org/ 提供给 IPN 模拟器时，我得到了所需的“IPN 已发送且握手已验证”。信息。但是使用https://paypal-api.tempel.org/，这是 same 证书，但只是同一服务器上的不同 Apache 站点，我仍然收到“握手未验证”错误消息。我没有想法。
谁能看出https://h1.tempel.org/ 和https://paypal-api.tempel.org/ 之间的证书有什么区别？
【问题讨论】：
PayPal 可能已更改其客户端证书或其 CA。 【参考方案1】：我终于设法让它再次工作 - 部分。
在我发现模拟器接受https://h1.tempel.org/ 但不接受https://paypal-api.tempel.org/ 之后，即使两者都是返回状态200 的有效页面，并且两者都在同一台服务器上并使用相同 SSL 证书，我重新配置了 Web 服务器，以便 h1 子域也可以为 cgi 处理程序提供服务。然后我更新了 https://www.paypal.com/cgi-bin/webscr?cmd=_profile-ipn-notify 的处理程序 URL 以使用 h1 子域（而不是 paypal-api，这解决了这个问题，至少对于新的 Paypal 交易。
但是，尝试重新发送之前失败的通知仍然失败，因为它们继续使用旧 URL。
Paypal 支持响应
在最终联系了 Paypal 业务支持后，我了解到：
显然，他们正在使用 Cisco / Talos Intelligence 对他们联系的任何外部页面进行评分。
由于某些莫名其妙的原因，Talos 目前将我的 IPN URL's domain 评为“恶意软件”！没有其他黑名单站点对我的站点进行评级，因为它几乎是不可见的，并且除了 IPN cgi 处理程序之外，该站点没有提供任何内容，它只提供状态为 200 或 500 的空回复，具体取决于内容。
这意味着我现在必须让 Talos 移除该恶意软件评级（24 小时后仍悬而未决！）。有趣的是，Talos 只对域进行评级，而不是对该服务器的 IP 地址服务的所有站点进行评级。因此，即使是 payments.tempel.org，它实际上只是 paypal-api.tempel.org 的 ServerAlias，也被评为正常。
Paypal 支持人员还解释说，通知 URL 存储在数据库中，并在尝试重新发送失败的通知时被重新使用，因此尽管我告诉过它，它仍会继续使用旧的（当前恶意软件评级的）URL Paypal 现在使用不同的 URL。
但现在，一天后，再次尝试重新发送失败的消息时，突然确实使用新设置的 URL，不管 Paypal 支持人员解释说重新发送不会发生这种情况。 p>
所以，这个故事的寓意：有时这不是你的错，而是 Paypal 弄错了。或思科。
另外值得注意的是：如果 Paypal 突然决定将您的 IPN URL 视为恶意软件站点的一部分，他们不会提醒您。帮助或他们的测试工具中的任何内容都不会告诉您为什么他们不再与您联系，让您猜测直到您联系他们（在这方面，最初的答案（现已删除）建议我需要联系 Paypal 是正确的直接因为Paypal出于某种原因将我列入黑名单）。他们甚至无法将您列入白名单，而是让您与思科争夺将您的评级恢复为“无害”的问题。
【讨论】：
以上是关于我的服务器突然不再接收来自 Paypal 的 IPN 请求，工作了多年的主要内容，如果未能解决你的问题，请参考以下文章