DNSのない証明書には根本的な欠陥がありますか？
私はセキュリティ作業に不慣れで、他の誰かの設計を実装しています。この設計では、DNSがなくIPのみの環境でTCP TLSを使用するサーバーが必要です。
私は一般的な証明書チェーン（自己署名ルート証明書->中間証明書->エンドポイント証明書）を使用しています。 TCPサーバーは、中間証明書のパブリック部分がコードに固定されているクライアントにエンドポイント証明書を提示します。クライアントが接続すると、中間証明書が署名に使用されていることを確認しますエンドポイント証明書。
私が理解しているように、クライアントが接続すると、通信を保護するために鍵交換が行われ、クライアントは証明書チェーンの検証を使用して、サーバーが本人であることを確認します。しかし、このスキームでは、詐欺師は実際のサーバーから証明書を取得した後に証明書を提示することはできませんか？
これを欠陥と誤解していますか？私の理解では、証明書を関連付けるDNS名がないと、チェーンをチェックする（署名された署名済み親証明書があるかどうかにかかわらず）だけでは不十分です。ここで他に何ができますか？
しかし、このスキームでは、詐欺師は実際のサーバーから取得した証明書を提示できないのではないでしょうか。
詐欺師は実サーバーの証明書を提示して利用することはできません 一致する秘密鍵も持っている 。これはSAN DNSエントリまたはIPエントリのどちらを使用して、提示されている証明書を識別するかはtrueです。
攻撃者がサーバーの証明書を送信すると、クライアントは共有秘密鍵（セッションの対称暗号鍵の生成に使用）をその証明書の公開鍵で暗号化します。その後、攻撃者は証明書の秘密鍵を持っていないため、シークレットを回復できなくなり、TLSハンドシェイクを完了できなくなります。
インスピレーションを得るために、 [〜＃〜] ssh [〜＃〜] 鍵交換がどのように機能するかを見てください：
クライアントは、IPアドレスとハッシュを照合する「既知のサーバー」のテーブルを維持します。サーバーに接続すると、クライアントはサーバー証明書（公開鍵）を受け取り、そのハッシュを計算して、「既知のサーバー」テーブルでサーバーのIPアドレスを検索します。
クライアントが以前にこのサーバーを見たことがある場合は、証明書の計算されたハッシュをサーバー用に記録したものと比較できます。それらが一致する場合、すべてが正常であり、接続が継続します。そうしないと、SSHプログラムは大きな警告メッセージをスローし、接続を拒否します。
クライアントが初めてサーバーに接続するとき、ユーザーはこのサーバーを見たことがないことを通知され、サーバーの証明書を既知のサーバーテーブルに追加することを提案します。この手順は、既知のサーバーテーブルにサーバーの証明書の詳細を手動で入力することで回避できます。