Paypalは、すべてのWebエンドポイントとAPIエンドポイントでSSL証明書をアップグレードしています。コンピューティングパワーの進歩に関するセキュリティ上の懸念により、業界は1024ビットSSL証明書(G2)を段階的に廃止し、2048ビット証明書(G5)を優先し、データ伝送を保護するためのより強力なデータ暗号化アルゴリズム、SHAに移行しています古いSHA-1アルゴリズム標準よりも-2(256)。
ただし、まだアップグレードに対応していないシステムを使用しており、サーバーの更新は選択できません。したがって、Paypalがnginxサーバー(更新をサポートする)が古いサーバーの代わりにそのエンドポイントにアクセスしているとPaypalが判断できるように、Paypalエンドポイントをプロキシ(nginx)することを考えます。これは可能ですか?そうでない場合、このアップグレードをバイパスするための可能なオプションは何ですか?
Nginxプロキシの設定例は次のとおりです
サーバー{ listen 80; server_name api.sandbox.Paypal.com; access_log /var/log/nginx/api.sandbox.Paypal.com。 access.log; error_log /var/log/nginx/api.sandbox.Paypal.com.error.log; location/nvp { proxy_pass https ://api.sandbox.Paypal.com/nvp; proxy_set_header X-Real-IP $ remote_addr; proxy_set_header X-Forwarded-For $ proxy_add_x_forwarded_for; proxy_set_header Host $ http_Host ; } }
これはアップグレードではなく、リビルドとリファクタリングの機会です。これらのRHEL4システムが稼働してからどのくらいになりますか? 2006? 2007?
組織は Red Hatライフサイクルスケジュール とサポート期間の終了に関する警告を無視しましたか?最後のパッケージのリリース以降、これらのシステムはすべて比類のない状態で実行されているということですか?
まだRHEL4を使用している理由を教えてください。それは本当に2012年に廃止されました。その期間、単純に再構築する機会がありました。
この特定の問題については、最新のOSに再構築するための労力を評価することが最善のアプローチだと思います。 EL6またはEL7は良い候補であり、積極的なサポートの対象となります。
風に逆らって歩くのはとても難しい(そしてこの場合は役に立たない)ので、代わりにそれに従ってください。アップグレードは時々お尻の痛みかもしれませんが、それだけの価値があることは理解できます。
また、2048-bit
証明書は、今後数年間でさらに多くの問題を引き起こすでしょう。 Paypalだけでなく、他の多くのサービスは1024-bit
とアップグレードをフォローできないと、物事を機能させるのに夢中になります。
原則として、プロキシを使用しても機能しない理由はありません。その特定の構成が機能するかどうかを知るのに十分なnginxについては知りません。
検討する価値のある別のオプションは、OS全体をアップグレードせずにssl/tlsライブラリとルート証明書ストアをアップグレードすることです。明らかに、これにはある程度の互換性/回帰テストが必要であり、問題のライブラリをソースからビルドする必要があるでしょう。
最新の証明書(> = 2048ビットルートから、sha256署名を使用)を処理できない場合、Paypalだけでなく、近い将来、ほとんどのsslサービスで問題が発生するようになります。
Ewwhiteが指摘したように、 RHEL4は2012年からEOLになっています 。
なぜアップグレードできないのですか? 問題がライセンス費用である場合、 CentOS があります。。問題が何らかのコード依存関係である場合は、ええと。私は、コストの場合のように、それに対するグリブの答えはありませんが、時間の経過とともに悪化するだけです。
これが、法令遵守の理由から(そしてインターネットから遠く離れて)守らなければならないレガシーなものだったのかと思いますが、これはあなたが話している実際の事業分野です。あなたは統計になりたくありません。ただリマインダー:ホームデポはデータ侵害に $ 43,000,0 費やしました。
「サーバーの更新はオプションではありません」というスタンスを再検討してください。