SSH Tectia

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

証明書を使用したサーバの認証は、初回接続時の中間者攻撃の可能性が排除されることを除けば、公開鍵認証を使用したサーバの認証と同様に行われます。サーバ証明書にある認証局の署名によって、最初の接続時であっても、サーバ証明書の信頼性が保証されます。

証明書を使用したサーバ認証の概要を以下に示します。

  1. サーバは公開鍵が含まれている証明書をクライアントに送信します。またこのパケットには、サーバの秘密鍵によって署名された、セッションに対して一意のランダム データも含まれています。

  2. サーバの証明書は、CA (認証局) の秘密鍵によって署名されているため、クライアントは CA 証明書を使用してサーバの証明書の有効性を検証できます。

  3. クライアントは、証明書がサーバの名前または IP アドレスと一致することを確認します。Connection Broker の設定ファイルで end-point-identity-check が有効になっている場合、クライアントは、サーバのホスト名または IP アドレスと、サーバ証明書で指定されているサブジェクト名またはサブジェクトの代替名 (DNS アドレス) とを比較します。

    Connection Broker の設定ファイルで end-point-identity-check が無効になっている場合、サーバ ホスト証明書内のフィールドは検証されず、有効期間と CRL チェックのみに基づいて証明書が受け入れられます。

    [警告]警告

    クライアントでのエンドポイント同一性チェックを無効にすることはセキュリティ上危険です。無効にすると、サーバ ホスト証明書の発行元と同一の信頼された CA によって発行された証明書を持っている者が、サーバに対して中間者攻撃を実行できることになります。

  4. クライアントは、最初のパケットの署名を確認して、サーバが有効な秘密鍵を持っているかどうかを検証します。

認証中、システムは証明書が無効になっていないかどうかを確認します。これは、OCSP (Online Certificate Status Protocol) または、LDAP または HTTP リポジトリで発行される CRL (証明書失効リスト) のいずれかを使用して実行されます。

証明書に有効な Authority Info Access 拡張が含まれているか、または OCSP レスポンダが別途設定されている場合、OCSP は自動的に使用されます。OCSP レスポンダが定義されていないか、または OCSP への接続に失敗した場合は、CRL が使用されます。LDAP が CRL の発行方法として使用されている場合、LDAP リポジトリの場所もまた、ssh-broker-config.xml ファイルで定義されます。