コンテンツにスキップ

証明書を使用したサーバ認証

証明書認証は、公開鍵認証が持つ問題の一部を解決します。公開鍵ホスト認証の場合、システム管理者は、各クライアントの既知のホスト一覧にすべてのサーバのホスト公開鍵を追加する必要があります。または、不明なホストに接続する時にホストの識別情報を確認することをクライアントユーザに依存することになります。証明書認証は、認証局 (CA) と呼ばれる信頼されたサードパーティを使用して、ホストから来る情報の正しさを確認することでこの問題を防止します。

公開鍵認証と同様、証明書認証は、公開鍵/秘密鍵ペアを使用してホストの識別情報を確認します。ただし、証明書認証の場合、公開鍵はデジタル証明書に含まれ、この場合、2 つの鍵ペアが使用されます。ホストが 1 つの秘密鍵を保持し、CA が 2 番目の公開鍵を保持します。ホストは、CA から証明書を取得します。この証明書には、ホストに関する識別情報、ホスト公開鍵のコピー、および CA の秘密鍵を使用して作成されたデジタル署名が含まれています。この証明書は、認証プロセス中にクライアントに送信されます。ホストから送信された情報の完全性を確認するため、クライアントは CA ルート証明書に封印されている CA の公開鍵のコピーを持つ必要があります。

ホストの識別情報を確認するために CA ルート証明書をインストールすることは、ホスト公開鍵をインストールし、構成することに比べて、いくつかの利点があります。

  • 単一の CA 証明書を使用して、複数のサーバを認証することができます。

  • 管理者は、Windows グループポリシを使用して、Windows クライアントに CA 証明書をインストールすることができます。

  • 商業的に取得した証明書のルート証明書は、既にクライアント コンピュータで使用できる場合があります。Windows コンピュータでは、Internet Explorer で使用するための、一部のルート証明書があらかじめインストールされています。SSL/TLS 接続の場合、Reflection は、この証明書格納場所に既定で置かれた証明書をチェックします。

  • 必要なら、ホストは、クライアントシステムを何も変更することなく、同じ CA から新しい証明書を取得できます。

サーバ証明書認証は、次のような順序で実行されます。

  1. Secure Shell クライアントが接続を開始します。

  2. ホストは、その証明書をクライアントに送信します。

  3. クライアントは、CA ルート証明書を使用してサーバ証明書の有効性を確認します。

    メモ

    クライアントは、信頼されるルート格納場所に、すでに CA 証明書のコピーを持っている必要があります。(単一の CA 証明書を使用して、複数のサーバを認証することができます)。

  4. クライアントは、ホストの証明書に記載されているサーバ情報が対象ホストと一致することを確認します。

  5. ホストが証明書の公開鍵に対応する秘密鍵を保持していることを確認するため、クライアントは試行 (任意のメッセージ) をサーバに送信し、このメッセージ文に基づいてハッシュを計算します。

  6. サーバは、試行メッセージに基づいてデジタル署名を作成します。サーバは独立してメッセージハッシュを計算し、その秘密鍵を使用して計算されたハッシュを暗号化します。次に、サーバは、このデジタル署名を試行に添付し、この署名付きメッセージをクライアントに返信します。

  7. クライアントは、サーバの公開鍵を使用して署名を解読し、元のハッシュと自分で計算したハッシュを比較します。値が一致する場合、ホスト認証は成功します。

    メモ

    Reflectionクライアントは、Reflection証明書格納場所またはWindows証明書格納場所を使用して、ホスト証明書を確認できます。