サーバー間の通信シナリオがあります。ここでは、TLSサーバー認証にCA署名付き証明書を使用し、クライアント認証に自己署名証明書を使用したいと考えています。
このシナリオ(クライアント認証)の場合に自己署名証明書を使用する場合と比較して、CA署名証明書を使用することで得られる追加のセキュリティはありますか?
[〜#〜] updated [〜#〜]関連するクライアント証明書をサーバーのトラストストア/ホワイトリストにインポートしています。このコンテキストを前提として、CA署名付き証明書は追加のセキュリティ上の利点を提供しますか?
[これは、更新に関する質問の書き直しです。 改訂履歴 ]のオリジナルを参照してください
TLSクライアント認証はalmostの場合、常にサーバー側で独自の証明書カスタム検証コードを記述してTLSエンジンを拡張する必要があります。追加の検証コードなしでトラストストアに便乗することでこれを回避したようです。
重要な質問は次のとおりです。
サーバーがクライアント証明書を確認しているときに、サーバーがそれがあなたが発行した証明書であり、悪意のある人が発行した証明書ではないことをどのようにして確認しますか?。
あなたは言う:
関連するクライアント証明書をサーバーのトラストストア/ホワイトリストにインポートしています。
これはセキュリティ面では問題ないかもしれません。最初に尋ねる質問は、サーバートラストストアに他に何があるか、そしてホワイトリストに登録した証明書以外の証明書からの接続を受け入れるかどうかです。公に信頼されたすべてのルートCAを含むOSトラストストアについて話しているのですか、それとも、カスタムJavaトラストストアはホワイトリストを挿入する前は空ですか?)たとえば、パブリックCA Let's Encryptがトラストストアにある場合、Let's Encrypt証明書を持つ誰もがサーバーに接続できる可能性があります。
基本的に、作成した自己署名証明書はサーバーへの接続を確立できるonly証明書であると自分に納得させる必要があります。このように機能する製品を見たので、完全に遠くまで届くわけではなく、適切なセキュリティは可能ですが、他にいくつか考慮すべき点があります。まず、これが設定される通常の方法について説明してから、比較します。
通常、このような状況でclient-authが機能する方法は、次の2つの方法のいずれかです。
あなたが管理するプライベートCAがあります。有効なTLSクライアントの証明書のみを発行します。したがって、TLSサーバーは、クライアントがこのCAによって発行された証明書を提示し、それが本物であることを知っていることを簡単に確認できます。
クライアントは、Let's Encryptなどの公的に信頼されたCAから証明書を取得します。突然、Let's Encryptによって証明書が発行されたことを確認するだけでは十分ではありません。インターネットの半分にはそのような証明書があるため、何も証明されません。ここでは、「TLSサーバー」が「TLSクライアント」のドメイン名のホワイトリストを保持するようにします。クライアント証明書を検証するときは、通常のすべての有効性チェックに加えて、証明書のDNがホワイトリストのドメイン名と一致する必要があります。
必要なセキュリティ目標は、TLSクライアント(およびTLSクライアントのみ)がTLSサーバーへの接続を確立できることです。あなたは確かにあなたが説明したシステムでこれを達成することができます。初期設定はより単純になりますが、長期的には、追加の時間と労力の点で、またはそれほど長い時間で変更する必要がなかった場合のいずれかで、追加の運用上の複雑さが戻ってきます。それがどのように機能するか誰も覚えていません。必ず準備してください徹底的それがどのように機能するかに関するドキュメント!