PayPal 正在升级所有 Web 和 API 端点上的 SSL 证书。由于对计算能力进步的安全担忧，业界正在逐步淘汰 1024 位 SSL 证书 (G2)，转而采用 2048 位证书 (G5)，并转向更高强度的数据加密算法来保护数据传输，SHA-2 (256) 取代了较旧的 SHA-1 算法标准。
但是，我们仍在使用与升级不兼容的系统，更新我们的服务器不是一种选择。因此，我们的想法是代理（nginx）paypal 端点，以便 paypal 认为 nginx 服务器（支持更新）正在访问该端点而不是我们的旧服务器。这可能吗？如果不可能，有哪些可能的选项可以绕过此升级？
以下是 nginx 代理的配置示例
服务器 {
听80；
服务器名称api.sandbox.paypal.com；
访问日志/var/log/nginx/api.sandbox.paypal.com.access.log；
错误日志 /var/log/nginx/api.sandbox.paypal.com.error.log;
位置 /nvp {
代理密码 https://api.sandbox.paypal.com/nvp;
proxy_set_header X-真实IP $remote_addr；
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header 主机 $http_host;
}
}
答案1
这与其说是升级，不如说是重建和重构的机会。这些 RHEL4 系统投入生产多久了？2006 年？2007 年？
您的组织是否忽略了Red Hat 生命周期计划以及关于支持期结束的警告？这是否意味着自上次软件包发布以来，所有这些系统的运行情况都无法与上次相比？
您能解释一下为什么您还在使用 RHEL4 吗？它实际上在 2012 年就停产了。在那段时间里，我们有机会简单地重建。
对于这个特定问题，我认为最好的方法是评估重建到较新操作系统的努力。EL6 或 EL7 将是不错的选择，并将获得积极支持。
答案2
逆风而行太难了（而且在这种情况下毫无用处），那么为什么不顺风而行呢？我可以理解升级有时可能会很麻烦，但这是值得的。
此外，如果现在还不能使用2048-bit证书，那么在未来几年里，你就会遇到更多问题。我想，不仅是 PayPal，很多其他服务也会忘记这一点1024-bit，如果不能跟上升级，你就会疯狂地让事情正常运转。
答案3
原则上，我认为使用代理没有理由行不通。我对 nginx 了解不够，不知道该特定配置是否有效。
另一个值得考虑的选项是升级 ssl/tls 库和根证书存储，而不升级整个操作系统。显然，这需要一定程度的兼容性/回归测试，并且可能涉及从源代码构建相关库。
如果您无法处理现代证书（来自 >= 2048 位根并带有 sha256 签名），那么您在不久的将来几乎会遇到任何 ssl 服务的问题，而不仅仅是 paypal。
答案4
正如 ewwhite 指出的那样，RHEL4 自 2012 年起已停产。
为什么不能升级？ 如果问题是许可成本，那么CentOS如果问题是某种代码依赖性，嗯。对于这个问题，我没有像对于成本那样的巧妙答案，但随着时间的推移，情况只会变得更糟。
如果这是出于法律合规原因而必须保留的遗留问题（并远离互联网），我可以理解，但这是你在谈论的实际业务。你不想成为一个统计数字。只是提醒一下：家得宝花费了4300万美元关于他们的数据泄露。
请重新考虑“更新我们的服务器不是一种选择”的立场。