ssl - 内部使用のためのSSL署名付き証明書

Question

TCP（JMSなど）とHTTPを介して通信する多くのコンポーネントで構成される分散アプリケーションがあります。すべてのコンポーネントは、内部IPアドレスを使用して内部ハードウェア上で実行され、一般にアクセスすることはできません。

SSLを使用して通信を安全にしたい。有名な認証局から署名付き証明書を購入するのは理にかなっていますか？または、自己署名証明書を使用する必要がありますか？

信頼できる証明書の利点についての私の理解は、権限は一般の人々から信頼できるエンティティであるということですが、それは一般の人々が特定のドメインのエンティティが彼らの言うとおりの人物であることを確認する必要がある場合にのみ問題になりますそれは。

したがって、私の場合、同じ組織が通信の両端のコンポーネント、およびその間のすべてに責任を負っている場合、公的に信頼されている機関は無意味です。つまり、自分のサーバー用の証明書を生成して署名すれば、それが信頼できることを知っています。また、組織外の誰もこの証明書を信頼するように求められることはありません。それが私の推論です-私は正しいですか、それとも既知の機関からの証明書を使用することにいくつかの潜在的な利点がありますか？

Answer 1

クローズド コミュニティ プロジェクトに外部パブリック CA を使用する必要はありません。多くの大規模な組織では、内部 PKI を運用して、このような内部プロジェクトの証明書を発行しています。PKI を使用する利点は、安全に配布された単一のルート証明書/トラスト アンカーに基づいて、さまざまなコンポーネント間に信頼関係を設定できることです。

ただし、プロジェクトで内部ユーザーが Web ブラウザーを介して内部サービスに安全に接続できる場合は、パブリック CA 発行の証明書の使用を検討することをお勧めします。別の方法は、サービスに接続する必要がある可能性のあるすべてのブラウザーがルート証明書を信頼していることを確認することです。これは、ブラウザの警告メッセージを防ぐためです。

Answer 2

忍者の侵入者があなたのサーバーを交換しようとしていると思わない限り、それはかなり安全だと思います。

サードパーティは、新しい証明書を「アップ＆生成」することを困難にするために存在します。誰かが同じ詳細で新しいマシンに自己署名証明書を再作成する可能性があります。それは同じ証明書ではなく、例外も追加する必要がありますが、ユーザーはおそらく違いを知らないでしょう。 。

Answer 3

システムがグループ内で実行されていて、それを拡張する計画がない限り (計画は変更されるため、覚えておいてください)、独自の単純な PKI インフラストラクチャをセットアップしても問題ありません。

組織を超えて拡大する場合は、ルート証明書を通信する関係者に配布するだけです。これにより、実際には、パートナーがパブリック CA インフラストラクチャに対してどの程度の信頼を置きたいかを、パートナーがきめ細かく制御できます。