SSL/TLS通信の流れ
※TLS1.2での内容です
SSLハンドシェイク
SSL/TLSはTCPを利用するため、まずTCPの3ウェイハンドシェイク(SYN→SYN/ACK→ACK)を行ってセッションを確立する。その後、SSLハンドシェイクを行い、そこで決めた情報を元にメッセージを暗号化する
① Client Hello
クライアントはまず、自身がサポートしているSSL/TLSバージョンや暗号スイートをサーバ側に提示する。
暗号スイートとは、鍵交換の方法、サーバ認証の方法、暗号化の方法、MACアルゴリズムをまとめた呼び方のこと。
その他、共通鍵作成のためのclientrandom(challenge)なども送る
② Server Hello
サーバは、クライアントから送られてきた暗号スイート一覧の中から使用できるものを選び、セッションIDと共に送信する。共通鍵作成に使用するserverrandomなど、クライアントと合わせる必要があるパラメータをServer Helloとして返す
③ Server Certificate
サーバは、"自分が本物である"と示すためにサーバ証明書と、サーバ証明書とチェーンで繋がる証明書(中間証明書,ルート証明書)を順に並べて送信する。
クライアントはサーバ証明書の階層をたどっていき、証明書に署名した認証局(CA)を確認し、サーバ証明書が信頼できる認証局によって署名されているかを検証する。
クライアント(Webブラウザなど)自身に事前登録されているルート証明書と照合し、安全であることが確認できたら共通鍵(の素となるプリマスターシークレット)を生成する
自己署名など認証局による署名ではなかった場合、以下のような警告が出るようになっている。よく見るやつ。
④ Server Key Exchange
サーバは、暗号化通信を行うためにの基となる値(プリマスターシークレット)を交換するための情報がない場合にのみ、プリマスターシークレットを秘密裏に交換するための情報をこのメッセージで送信する。
交換するための情報がないこと自体が少ないため、大抵の場合省略される
⑤ Certificate Request
サーバは、クライアントに認証を求める場合、クライアント証明書を要求するためにこのメッセージを送信する。
SSL/TLSでは、クライアント認証はオプションとなっている。
メッセージには許容可能な認証局のDN(Distinguished Name)のリストを含めて送信される
⑥ Server Hello Done
サーバは、Server Helloと関連するメッセージの終わりを示すためにこのメッセージを送信する。
送信後、クライアントからの応答を待つ
⑦ Client Certificate
クライアントは、サーバが⑤クライアントに認証を求めた場合にのみこのメッセージを送信する。
このメッセージには、⑤で指定された認証局から発行された証明書(または証明書のチェーン)を含めて送信する。
⑧ Client Key Exchange
クライアントは、プリマスターシークレットを公開鍵で暗号化してサーバに送る。
プリマスターシークレットは暗号化通信を行うための基になる値。受け取ったサーバは、秘密鍵で復号してプリマスターシークレットを取り出す。
⑨ Certificate Verify
クライアントは、⑦クライアントが証明書を送信した場合にのみこのメッセージを送信する。
クライアントは、今まで受信したHelloメッセージからデジタル署名(Certificate Verify)を生成し、サーバに送信する。
デジタル署名を受け取ったサーバは、クライアントから受け取った証明書を使い、デジタル署名の検証を行う
(※クライアントの証明書に含まれる公開鍵でこのデジタル署名を復号することで、デジタル署名の検証とクライアントの認証を完了する。)
検証が成功すると、その証明書が間違いなくクライアントのものであることが確認できる。
⑩ Change Cipher Spec
クライアントは、client randomやserver randomと合わせてプリマスターシークレットからマスターシークレットを生成し、さらにマスターシークレットから暗号化通信用の共通鍵を生成する。
その他、ブロック暗号用のIV,HMAC用の共通鍵を生成する。
これらの値は、Finishedメッセージ以降で使用する。
次に、使用する暗号アルゴリズムの準備が整ったことをサーバに通知する
⑪ Finished
クライアントは、鍵交換と認証処理が成功し、ハンドシェイクの終わりを示すためにこのメッセージを送信する。
このメッセージはクライアントとサーバで共有した秘密鍵で暗号化されたはじめのメッセージで、このメッセージより前にハンドシェイクで送受信したすべてのデータのHMACを含めて送信する。
サーバは、このHMACが正しいか検証する。
このメッセージによりクライアントが秘密鍵を知っていることが確認できる。
⑫ Change Cipher Spec
サーバは、クライアントから受信した暗号化されたプリマスターシークレットを、自身の秘密鍵を使って復号する。
次に複合したプリマスターシークレット及びclient random, server randomと合わせてマスタシークレットを生成し、さらにマスタシークレットから共通鍵を生成する。
この共通鍵は、クライアントが生成した共通鍵と同じになる。
次に、使用する暗号アルゴリズムの準備が整ったことをクライアントに通知する
⑬ Finished
サーバは、鍵交換と認証処理が成功し、ハンドシェイクの終わりを示すためにこのメッセージを送信する。
このメッセージより前にハンドシェイクで送受信したすべてのデータのHMACを含めて送信する。
このHMACは、クライアントから送信されたFinishedメッセージ⑪を含むハッシュ値のため、クライアントから送信されたハッシュ値と異なる。
クライアントは、このハッシュ値が正しいか検証する
今までやり取りしたメッセージが改ざんされていないこと、暗号化通信用の共通鍵とHMAC用の共通鍵(MAC鍵)がお互い同じものが生成されていることを確認する
⑭ アプリケーションデータの暗号化通信
ここからはデータ転送フェーズになる。ハンドシェイクフェーズで合意したアルゴリズム及び鍵を使用して、
クライアント・サーバ双方で改ざん検知をしながらデータを暗号化された状態で安全に送受信する。
通信の中で使われている技術
ハイブリッド暗号化方式
共通鍵暗号方式(暗号鍵と復号鍵に同じ鍵を使用する方式。対称鍵暗号、秘密鍵暗号)
公開鍵暗号方式(暗号化と復号化に異なる鍵を使用する方式。非対称鍵暗号)
を組み合わせた暗号化方式のこと。
①受信者(サーバ側)は公開鍵と秘密鍵を作成
②受信者は公開鍵をみんなに公開・配布し、秘密鍵だけを保管
③送信者は共通鍵(共通鍵暗号化方式で使用する鍵)を公開鍵で暗号化して送る
④受信者は秘密鍵で復号して、共通鍵を取り出す(この時点でメッセージの暗号・復号で使用する鍵が両者で共有される)
⑤送信者は共通鍵でメッセージを暗号化して送る
⑥受信者は共通鍵でメッセージを復号する
この方式がSSL/TLSでも使用されている。
※共通鍵そのものを暗号化して送るわけではなく、共通鍵の基となる値(プリマスターシークレット)を送信する。
ハッシュ関数
いかなる長さのデータを入力しても固定長の疑似乱数データを出力する関数のことで、MD5,SHA-1,SHA-2(SHA-256=64文字 , SHA-512=128文字など)がある。
ハッシュ関数を通すことで、短い固定長の別の値(ハッシュ値)が生成される。
デジタル署名
公開鍵暗号を用いてデジタル署名の正当性を確認する
署名の対象データハッシュ値を署名者の秘密鍵で暗号化(A)したものをデジタル署名とする
デジタル署名の検証者は、公開されている署名者の公開鍵(B)を使ってデジタル署名を復号した値と、署名の対象データのハッシュ値が一致することを確認(C)することでデジタル署名が正しいものであるかを確認する
これにより、署名者であることをBにより確認でき、署名はたしかに本人の行為によるものであることをAにより、署名の対象と署名が対応しているものであることはCにより保証される。
暗号スイート
SSL通信する際に、サーバとクライアントで利用可能な鍵交換の方法、サーバ認証の方法、暗号化の方法、MACアルゴリズムをまとめたもの。それぞれ許容するスイートが一致しない場合、SSL通信は失敗する。
DHE-RSA-AES256-SHA256というように、
鍵交換方法-サーバ認証方法-暗号化方法-MACアルゴリズム
を一意に認識する
メッセージ認証コード(MAC)
データが改竄されていないことを確認するための短い情報のこと。主にハッシュ関数に基づくHMACが使われている
デジタル証明書
最も上位にあるものがルート証明書、下位にあるものがエンドエンティティ証明書と呼ばれる。
エンドエンティティ証明書にはサーバ認証に用いるサーバ証明書、クライアント認証に用いるクライアント証明書がある。
ルート証明書を発行するルート認証局(CA)はWebブラウザにあらかじめ登録されており、設定から確認できる。
ルート証明書とエンドエンティティ証明書の間に証明書がある場合、(証明書のチェーンが3階層以上で構成されている場合)は、それを中間証明書と呼ぶ。※サーバ証明書は一般に3階層
証明書の構造
証明書の構造は標準化されており、代表的なものはX.509である。
実際はX.509形式をDER形式でエンコードしたバイナリファイル(.der)やBASE64形式でエンコードしたテキストファイル(.pem)として扱われている。
デジタル証明書には"署名前証明書"、"デジタル署名のアルゴリズム"、"デジタル署名"で構成される。
署名前証明書
サーバやサーバの所有者の情報。URLを表すコモンネームや有効期限、公開鍵が含まれている。
デジタル署名のアルゴリズム
一方向ハッシュ関数が含まれている
デジタル署名
署名前証明書をハッシュ化してできたハッシュ値(メッセージダイジェスト)を、認証局の秘密鍵で暗号化したもの
サーバ証明書を受け取った受信者は、証明書の中に含まれているデジタル署名を認証局の公開鍵(ルート証明書)で復号し、署名前証明書と比較する。一致していれば、証明書が改ざんされていない＝サーバは本物だとわかる
デジタル証明書が正当性であるという証明は公開鍵のため、デジタル証明書は、公開鍵証明書とも言える。
サーバ証明書を発行する流れ
1. SSL/TLS サーバで秘密鍵を作成する
負荷分散装置やSSLアクセラレーションなどで秘密鍵を作成する(使用する場合)
2. CSRを作成し、認証局へ提出
1で作成した秘密鍵を基に「CSR(Certificate Signing Request)」を作成し、認証局に提出する
CSRは署名前証明書の情報で構成されていて、作成する時にそれぞれ入力する。
CSRを作成するために必要な情報はDistinguished Name (DN)と呼ばれ、以下のような項目がある。
※ただし、申請する認証局によって項目は異なる
一般名称(CN)
組織名(O)
部門名(OU)
市町村名(L)
都道府県名(S)
国別コード(C)
作成後、認証局へ提出する。主要な認証局例としては
・シマンテック（Symantec）
・グローバルサイン（GlobalSign）
・サイバートラスト（cybertrust）
・Let’s Encrypt
などがある。(2026時点)
3. 認証局の審査を受ける
審査にパスしたら、CSRをハッシュ化し、認証局の秘密鍵で暗号化して、デジタル署名としてくっつける。
そして、認証局はサーバ証明書を発行し、要求元に送る。※サーバ証明書もランダムな文字列。
4. 認証局から受け取ったサーバ証明書をSSL/TLSサーバにインストールする
使用する認証局によっては、中間証明書も一緒にインストールする必要がある。
中間証明書
中間認証局が発行している証明書。認証局は大量の証明書を管理するために、ルート認証局を頂点とした階層構造になっており、中間認証局はルート認証局の認証を受けて稼働している下位認証局のこと
5. クライアント側設定(基本は不要)
公開されているCAの証明書を利用する場合、クライアントとなるPCやサーバOSは基本的にあらかじめ信頼しているルートCAを持っている。
⇒ 送られてきたサーバ証明書が信頼しているCA一覧(rootCA)で署名されていることを検証することができるため、基本的にはクライアント側での設定は不要。
またCAについてもLet's Encrypt などでは certbot 等により自動更新する構成が一般的
オレオレ証明書についてはこちら
参考