web-dev-qa-db-ja.com

TLS証明書検証の詳細

暗号化の基本は理解していますが、次の3つのステップについては確信がありません。

ステップ1：TLS証明書の計算方法

間違っている場合は修正してください：認証局は関連する証明書情報（証明書の申請者の公開鍵を含む）に対してハッシュ値を計算し、認証局の秘密鍵を使用してこのハッシュ値に署名します。このプロセスの出力は、対応する秘密キーにアクセスできるサーバーに展開できる単一の証明書ファイルです。

ステップ2：サーバーがTLS証明書に対応する秘密鍵を所有していることを確認する方法

クライアントは、TLSハンドシェイク中にサーバーから証明書を取得します。ただし、証明書だけではデータの信頼性を検証するには不十分です。 （誰でも秘密鍵を所有せずに証明書のコピーを送信できるため）対応する秘密鍵を使用して（おそらくハッシュを計算することによって）署名する必要がある追加のランダム情報が送信される必要があると思いますか？

クライアントはこのランダムな情報を証明書の公開鍵で復号化しますか？このチェックはどのように実行されますか？

ステップ3：証明書が信頼できる機関によって署名されていることを確認する方法

これは主に、（他の情報とともに）信頼できる機関の公開鍵を含むプリインストールされたブラウザテーブルで機能すると思います。

認証局の公開鍵を使用してハッシュ値を復号化し、それが証明書全体の自己計算ハッシュ値と一致するかどうかを確認していますか？

tlscertificatespublic-key-infrastructurecertificate-authoritydigital-signature
3
Mike76

質問1への回答：

はい。ただし、CAのルートがボールトのHSMでオフラインであり、電子的に盗むことはできません。ルートは、電子的に到達可能なコンピューターに直接接続されているHSMにある少数の中間証明書（バックアップおよびOCSPレスポンダー証明書など）に署名するために使用されました。

証明書を発行するには、CAの「バックエンド」：

  1. cSRを受け取る
  2. いくつかの検証方法（ACMEプロトコル、管理者のWebサイトで人間が[OK]をクリックするなど）
  3. 後の監査でチェックするための決定を行うために使用されるすべての決定と情報をログに記録します
  4. テンプレートと新しいシリアル番号/ランダム性のソースを使用して、X.690 DERでエンコードされた証明書データ（X.509 v3）を生成します。
  5. おそらく証明書の透明性SCTを取得します。
  6. hSMにblob（またはblobのハッシュ）に署名するように要求します。
  7. 署名を証明書に追加し、顧客向けストレージに送信します。

質問2への回答：

RSAキー交換では、クライアントはランダムなバイトシーケンスを生成し、サーバーの証明書の公開キーを使用してRSA暗号化を実行します。次に、クライアントは結果の暗号文をサーバーに送信し、サーバーがそれを復号化し（証明書の公開鍵に対応する秘密鍵を使用）、KDFのランダムな値と他の値を使用して対称鍵を生成し、結果の対称鍵で暗号化されたFinishedメッセージを送信します。クライアントは終了メッセージを確認します。サーバーは、RSA暗号化メッセージを復号化することによって、予期される対称鍵の生成にのみ成功できます。 https://tools.ietf.org/html/rfc5246#appendix-F.1.1.2

PFSとのDHE/ECDHE鍵交換では、サーバーは証明書の公開鍵に対応する秘密鍵を使用して一時鍵に署名し、これをServerKeyExchangeに送信します。クライアントは、証明書の公開鍵を使用して署名を検証します。 https://tools.ietf.org/html/rfc5246#appendix-F.1.1.

質問3への回答：ブラウザーには信頼されたルートのリストが含まれています（Mozilla Firefoxがこれを行います）、またはオペレーティングシステムによって提供された信頼されたルートのリストを使用します（Google ChromeはOSルートストアを使用します） 。ルートストアには、自己署名証明書と、証明書の使用目的を制限する可能性のあるそれらに関するいくつかのメタデータが含まれています。ブラウザには、Chrome Symantec-からの証明書の透明性を要求する）などの追加のチェックを追加するコードも含まれていますSHA1証明書の使用を許可する所有CAおよびカットオフ日。

ルートストアを使用してリーフサーバー/ドメイン証明書を検証する方法は、信頼できるルートからリーフへ、中間証明書のチェーンを構築して、一方が他方に署名することです。根は中間体に署名し、中間体は葉に署名します。チェーンには複数の中間体が存在する場合があります。中間体はリーフとともにサーバーから送信されます。 https://en.wikipedia.org/wiki/Certification_path_validation_algorithm

異なるコンピューターには異なるルートストアがあり、クロス署名を使用することにより、多くの異なるパスを構築できます。現在、ブラウザーは可能であればsha256のみのパスを構築しようとしますが、失敗して、sha1パスのみが構築されたことを示すエラーを生成するため、接続が安全でない可能性があります。

デジタル署名と暗号化を混同しないでください： https://security.stackexchange.com/a/87373/708

4
Z.T.