ホーム＞SSLサーバ証明書とは
公開鍵暗号

ハンドシェイク

ハンドシェイクとは

SSL/TLS　通信で、サーバーを認証し、「公開鍵」と「秘密鍵」を使って「共通鍵」を共有する過程を「ハンドシェイク」と呼びます。SSL/TLS　セッションは、常に「ハンドシェイク」から始まります。

「ハンドシェイク」平文のメッセージ交換から始まり、https 通信を確立するために欠くことのできないプロセスです。

SSLサーバ証明書を検証し、通信しているサーバーが真に意図したサーバーであるかの検証を行います。サーバーがクライアントを認証する場合はクライアント証明書を利用してクラインと認証が行われる場合もあります。
サーバーが認証されると、プリマスタシークレットの交換、セッションキーの共有の手順に進みます。このセッションキーが「共通鍵」となります。

RSAサーバ証明書のハンドシェイク

注：以下ではクライアントを認証を行わない手順について説明しています。

ClientHelloクライアントがサーバーに対して、クライアントが利用可能な SSL/TLS バージョン番号のリスト、利用可能な CipherSuiteのリスト、クライアント日時の4biteにランダムな284biteの数値を加えた324biteのランダム値、セッションID、などサーバーとのSSL通信条件を決めるために必要な情報を送信します。
ServerHelloサーバーはClientHelloのリストから選択し利用を決定した SSL/TLS バージョン番号、CipherSuite、サーバー日時の4biteにランダムな284biteの数値を加えた324biteのランダム値、セッションIDをクライアントに送信します。
- 現在安全とされているSSL/TLS バージョン番号はTLSv1.2です。 CipherSuiteは「鍵交換アルゴリズム」「認証アルゴリズム」「ストリーム暗号」「ハッシュアルゴリズム」を定義します。
  SSL/TLS バージョン番号、CipherSuiteについて詳しくは以下を参照ください。
  詳細：SSLProtocolとSSLCipherSuite
- サーバーのランダム値はクライアントのランダム値と合わせてクライアントがマスターキーを生成するために利用されます。
- セッションIDはClientHelloによって異なったタイプになります。
  新規接続の場合は新しいセッションIDが作成されます。
  セッション再開の場合はクライアントとサーバーのセッションIDは同一になります。
  サーバーがセッションの再開を認めない場合はnull セッションIDとなります。すなわちセッションIDは送られません。
Certificateサーバーは自身の証明書を送信します。証明書には公開鍵が含まれています。中間証明書等、証明書のチェーンがある場合はそれらの証明書も送付されます。
ServerHelloDoneサーバーは ServerHelloDone メッセージを送信し、Hello メッセージフェーズが終了したことを伝えます。
ClientKeyExchangeクライアントはサーバーの証明書を検証し、認証を行います。認証の詳細手順は以下を参照ください。
詳細：クライアント（ブラウザ等）のSSLサーバー証明書検証手順
サーバーを認証できない場合、発生した問題とともにハンドシェイクの失敗が、ブラウザ等に表示されます。
サーバーの認証に成功すると、クライアントは「プリマスタシークレット」と呼ばれるランダム値を作成し、証明書に含まれる公開鍵を使って暗号化します。
クライアントは「プリマスタシークレット」をサーバーに送信します。この段階の通信自体はまだ暗号化されていませんが、「プリマスタシークレット」は暗号化されていますので第三者が解読することはできません。
サーバーは自身の秘密鍵で「プリマスタシークレット」を復号化します。この時点で、サーバーとクライアントだけが「プリマスタシークレット」を共有できたことになります。
ChangeCipherSpecクライアントは、Client Hello と Server Hello に含まれていた324biteのランダム値と「プリマスタシークレット」を使って「マスタシークレット」を生成します。クライアントはさらに「マスタシークレット」から「MACシークレット」と「セッションキー」を作成します。ここまでの通信自体は暗号化されていませんが、以降のクライアントからの通信を暗号化するための方法 Change Cipher Spec をサーバーに通知します。
FinishedクライアントはFinished メッセージをサーバーに送ります。このメッセージはChangeCipherSpecで決められた方法で送られる最初の暗号化された通信です。サーバーはFinished メッセージの内容がこれまでの手続き過程と照らし合わせ正しいかを確認する必要があります。
ChangeCipherSpecサーバーも、Client Hello と Server Hello に含まれていた324biteのランダム値と「プリマスタシークレット」を使って「マスタシークレット」を生成します。サーバーはさらに「マスタシークレット」から「MACシークレット」と「セッションキー」を作成します。ここまでのサーバーからの通信は暗号化されていませんが、以降のサーバーからの通信を暗号化するための方法 Change Cipher Spec をサーバーに通知します。サーバーの作成した「マスタシークレット」、「MACシークレット」、「セッションキー」、 Change Cipher Spec はクライアントが作成したものと同じになります。
FinishedサーバーはFinished メッセージをクライアントに送ります。このメッセージはChangeCipherSpecで決められた方法でサーバーから送られる最初の暗号化された通信です。クライアントはFinished メッセージの内容がこれまでの手続き過程と照らし合わせ正しいかを確認する必要があります。
SSL ハンドシェイクが完了し、セッションが開始されます。クライアントとサーバーは「セッションキー」を使用して、相互に送信されるデータの暗号化と解読、および整合性の確認を行います。

楕円暗号サーバ証明書（ECDHE_ECDSA）のハンドシェイク

注：以下ではクライアントを認証を行わない手順について説明しています。

ClientHelloクライアントがサーバーに対して、クライアントが利用可能な SSL/TLS バージョン番号のリスト、利用可能な CipherSuiteのリスト、クライアント日時の4biteにランダムな284biteの数値を加えた324biteのランダム値、セッションID、などサーバーとのSSL通信条件を決めるために必要な情報を送信します。加えてライアントが利用可能な楕円曲線名（ellipiptic_curves）とECポイント形式（ec_point_formats）を送信します。
ServerHelloサーバーはClientHelloのリストから選択し利用を決定した SSL/TLS バージョン番号、CipherSuite、サーバー日時の4biteにランダムな284biteの数値を加えた324biteのランダム値、セッションIDをクライアントに送信します。加えて利用を決定した楕円曲線名（ellipiptic_curves）とECポイント形式（ec_point_formats）を送信します。
- 現在安全とされているSSL/TLS バージョン番号はTLSv1.2です。 CipherSuiteは「鍵交換アルゴリズム」「認証アルゴリズム」「ストリーム暗号」「ハッシュアルゴリズム」を定義します。
  SSL/TLS バージョン番号、CipherSuiteについて詳しくは以下を参照ください。
  詳細：SSLProtocolとSSLCipherSuite
- サーバーのランダム値はクライアントのランダム値と合わせてクライアントがマスターキーを生成するために利用されます。
- セッションIDはClientHelloによって異なったタイプになります。
  新規接続の場合は新しいセッションIDが作成されます。
  セッション再開の場合はクライアントとサーバーのセッションIDは同一になります。
  サーバーがセッションの再開を認めない場合はnull セッションIDとなります。すなわちセッションIDは送られません。
- ライアントとサーバー双方がが利用する楕円曲線名（ellipiptic_curves）とECポイント形式（ec_point_formats）が決定されます。
Certificateサーバーは自身の証明書を送信します。中間証明書等、証明書のチェーンがある場合はそれらの証明書も送付されます。
ServerKeyExchangeサーバーは楕円曲線名とサーバーの公開鍵を署名付きで送ります。
ServerHelloDoneサーバーは ServerHelloDone メッセージを送信し、Hello メッセージフェーズが終了したことを伝えます。
ClientKeyExchangeクライアントはサーバーの証明書を検証し、認証を行います。認証の詳細手順は以下を参照ください。
詳細：クライアント（ブラウザ等）のSSLサーバー証明書検証手順
サーバーを認証できない場合、発生した問題とともにハンドシェイクの失敗が、ブラウザ等に表示されます。
サーバーの認証に成功すると、クライアントは利用が合意された楕円曲線名（ellipiptic_curves）とECポイント形式（ec_point_formats）から、自身の公開鍵を作成しサーバーに送ります。同時に、サーバーの公開鍵と自身の秘密鍵から「プリマスタシークレット」と呼ばれる共通鍵を作成します。
一方、サーバーはクライアントの公開鍵と自身の秘密鍵で「プリマスタシークレット」を作成します。楕円曲線暗号の原理から、クライアントの作成した「プリマスタシークレット」とサーバーが作成した「プリマスタシークレット」は一致します。この時点で、サーバーとクライアントだけが「プリマスタシークレット」を共有できたことになります。
ChangeCipherSpecクライアントは、Client Hello と Server Hello に含まれていた324biteのランダム値と「プリマスタシークレット」を使って「マスタシークレット」を生成します。クライアントはさらに「マスタシークレット」から「MACシークレット」と「セッションキー」を作成します。ここまでの通信自体は暗号化されていませんが、以降のクライアントからの通信を暗号化するための方法 Change Cipher Spec をサーバーに通知します。
FinishedクライアントはFinished メッセージをサーバーに送ります。このメッセージはChangeCipherSpecで決められた方法で送られる最初の暗号化された通信です。サーバーはFinished メッセージの内容がこれまでの手続き過程と照らし合わせ正しいかを確認する必要があります。
ChangeCipherSpecサーバーも、Client Hello と Server Hello に含まれていた324biteのランダム値と「プリマスタシークレット」を使って「マスタシークレット」を生成します。サーバーはさらに「マスタシークレット」から「MACシークレット」と「セッションキー」を作成します。ここまでのサーバーからの通信は暗号化されていませんが、以降のサーバーからの通信を暗号化するための方法 Change Cipher Spec をサーバーに通知します。サーバーの作成した「マスタシークレット」、「MACシークレット」、「セッションキー」、 Change Cipher Spec はクライアントが作成したものと同じになります。
FinishedサーバーはFinished メッセージをクライアントに送ります。このメッセージはChangeCipherSpecで決められた方法でサーバーから送られる最初の暗号化された通信です。クライアントはFinished メッセージの内容がこれまでの手続き過程と照らし合わせ正しいかを確認する必要があります。
SSL ハンドシェイクが完了し、セッションが開始されます。クライアントとサーバーは「セッションキー」を使用して、相互に送信されるデータの暗号化と解読、および整合性の確認を行います。

クライアント（ブラウザ等）のSSLサーバー証明書検証手順

クライアント（ブラウザ等）は以下の手順でSSLサーバー証明書を検証し、サーバーが意図した接続先であることを確認します。

SSLサーバー証明書が現在日時で有効化を検証します。SSLサーバー証明書の有効期限に現在の日時が含まれていない場合は、クライアントは検証を中止しエラーを通知します。有効であることが確認できたら次の手順に進みます。
クライアントはSSLサーバー証明書のチェーンをさかのぼり、その証明書の root 証明書（CA 認証局の証明書）が何かを確認します。見つかった root 証明書（CA 認証局の証明書）がクライアントシステムの信頼できる root 証明書リストに含まれているかを検証します。リストに含まれていない場合は「信頼できない証明書」エラーを表示し検証を中止します。信頼できる root 証明書（CA 認証局の証明書）に基づいて発行されたSSLサーバー証明書であることが確認できた場合は次の手順に進みます。
SSLサーバー証明書には証明書の認証局（CA）が行った署名（signature）が含まれています。クライアントは認証局（CA）の公開鍵を使って、署名（signature）を検証します。
偽装された証明書の場合、検証は失敗します。また、署名（signature）に利用された認証局（CA）の秘密鍵と、検証に利用される認証局（CA）の公開鍵が一致しない場合も検証は失敗します。
署名が検証できれば、信頼のチェーンが成立し、SSLサーバー証明書の記載内容が信頼できます。
クライアントはサーバー証明書に記載されているホスト名と、実際に接続しているホスト名が一致するかをチェックします。これまでの過程で証明書が有効であることが検証済みであっても、この検証を経ないと安全は https 接続は確保できません。
検証を行わないと中間者攻撃などが可能になってしまいます。一致しない場合ブラウザは証明書とホスト名が不一致の警告を出します。メールクライアントの場合、この検証を行わないこともあります。

上記が完了するとクライアントとサーバーの安全な接続が確立されます。

なお、上記では証明書の失効チェックについての説明を省いていますが失効チェックについては以下を参照ください。

詳細：失効チェック

▲このページの先頭へ戻る

DigiCert.com