自己署名証明書を持つシステムとの統合を行っています。最初の開発では、いくつかのエラーを回避するために証明書チェックを無視することを選択します。
スレッド "main"の例外javax.net.ssl.SSLHandshakeException:Sun.security.validator.ValidatorException:PKIX path building failed:Sun.security.provider.certpath.SunCertPathBuilderException:can not find valid certificate path to request target
最初に、Docker環境でJava keytool
を使用して証明書を追加する方法を理解する必要があるためです。
しかし、私の質問は、その場合、自己署名証明書を「信頼できる証明書」としてインポートすることの利点は何ですか?
プロバイダーと統合する公式サービスの場合は、セキュリティのために本当に有効な公開署名証明書をインストールする必要があります。
自己署名証明書を使用してプロバイダーを続行する必要があると仮定すると、証明書を無視することと信頼できるものとして追加することの大きな違いは、次のシナリオです。これは、中間者攻撃の例としてDNSポイズニングを利用しています。
次の例を見てください。
api.example.com
には、IPでリッスンする拇印XXXを含む自己署名証明書があります5.5.5.5
。api.example.com
解決6.6.6.6
-サムプリントはYYYになります。api.example.com
at 6.6.6.6
。秘密キーが一意であり、危険にさらされていない既知の適切な自己署名証明書をインポートすることにより、接続は完全なグローバルCA PKI署名証明書と同じくらい安全です。結局のところ、これらもまた、ある時点で単純に格納され、信頼されます。
PKI CA署名付き証明書を取得する理由は、セキュリティ以上の実用性の1つです。多くのクライアントで自己署名証明書を信頼する必要がある場合、それは多くの作業になる可能性があります。そして、鍵のローテーションを行うと、その作業がほぼ指数関数的に増加します。
開発時などにサーバーとクライアントを制御していて、プライベートCAを設定するスキルやリソースがない場合は、特定の自己署名証明書をトラストストアに追加してもそれほど問題ではありません。 any証明書を受け入れることは悪いことです。決して行わないでください。
証明書のチェックを無視すると、他のシステムとの間で中間者の位置を獲得できる(トラフィックを変更できる)誰でも、プレーンテキストのトラフィックを読み取り/変更できます。攻撃者は、自己署名証明書を使用して独自のTLSサーバーを起動し、トラフィックをルーティングして復号化し、実サーバーにプロキシすることで、TLS/SSLトンネルを破るだけです。この攻撃を非常に簡単にする多くのツールがあります。たとえば、HTTPSの場合は mitmproxy 、TLS/SSLの場合は一般的に stunnel です。
攻撃は 多くの異なる方法 で中間者の位置に入る可能性があります。したがって、ネットワークセキュリティの専門家であっても、攻撃者がこのポジションを獲得する方法がないことを完全に排除するのは困難です。
自己署名証明書を公開署名証明書に置き換える方法がない場合は、自己署名証明書をJavaを使用してキーストアに追加することにより、手動で信頼できます。keytool
このストアを信頼します。これは Certificate or Public Key Pinning と呼ばれることもあります
証明書は、署名者が署名者を保証できる方法です。署名者を信頼する場合は、証明書と署名済み公開鍵を信頼できます。署名者を信頼する場合は、証明書を無視できます。
より現実的な言葉で:
例1:Cindy Certificateauthorityは非常によく知られています。誰もがシンディを知っています。 Cindyは、他の人に紹介する前に、本当の人を確認することで非常に高い評価を得ています。 Pablo Pubkey(有名で信頼できるセールスマン)であると主張する誰かが、あなたに何かを売りたいと思っています。シンディはあなたをこの人に紹介し、彼はパブロだと言います。あなたはシンディを信頼しているので、その人はパブロであると信じているので、あなたはパブロにあなたのクレジットカード番号を教えて、物を買うことにしました。
例2:子供の頃から、フレディフレンドと一緒に育ちました。あなたはフレディが誰であるか知っています-あなたは幼稚園で彼に会い、あなたと一緒に彼が大人になるのを見ました。フレディはセールスマンでもあります。フレディと話をしたい場合は、フレディを見つけに行ってください。あなたを紹介する必要はありません。
最初の例では、特定の公開鍵の所有者を信頼する認証局に頼っていました。 2番目の例では、公開鍵を直接信頼していて、第三者がそれを所有していることを知らせる必要がありませんでした。たとえば、ソフトウェアがユーザーに公開鍵を発行し、それらの公開鍵をソフトウェアのデータベースに関連付ける場合があります。この2番目の例は、自己署名証明書と未署名証明書がある場合とまったく同じです。