以下は、某メルマガに書いた記事です。
オリジナルはこちら
httpsのプロトコル（通信手順）解説の２回目です。
「２回目なのになぜその１２？」と思われた方はhttpsその１から順にご覧ください。
予備知識だけでその１～その１０までの１０回分の解説が必要になっています。
今回もお楽しみください。
今回は、httpsの通信手順（プロトコル）解説の続きとなります。 通信手順といってもそんな難しいことをやっているわけではあり ません。いつも言っているようにコンピュータ同士でチャットの ようなものです。チャットと言ってわかりにくければショート メッセージによる会話のようなものです。 そのチャットの中でお互いに必要な情報をやりとりします。 httpsの場合であれば、「あんただれ？」とか「俺は暗号方式○○ か△△が使えるんだけど、そっちは？」などというやりとりを するわけです。 このやりとりが終われば、実際に取り決めた内容に応じて目的 の通信を始めます。 この前段のやりとりの部分は「TLSハンドシェイク」と呼ばれ httpsのキモとなる部分なのですね。 1. TLSハンドシェイク －－－－－－－－－－－ 前回のおさらいになりますが、httpsでは次の順でやりとりを行い ます。 1. TLSハンドシェイク 1.1 ご挨拶 1.2 サーバ証明書の検証 1.3 （クライアント証明書の検証） 1.4 鍵交換 1.5 暗号化通信への移行 2. 暗号化した状態でのhttp このうち、「1.1 ご挨拶」を前回解説しました。 httpsは「安全なhttp」が目的です。安全を担保するには通信の 方式や暗号化の方式を決めるだけではなく、通信相手がホンモノか どうかを見極めなければなりません。 今回は通信相手を見極めるための「1.2 サーバ証明書の検証」に ついて解説します。 2. サーバ証明書の検証 －－－－－－－－－－－ 前回と同じですが、用語の確認です。 クライアント： 今からサーバにつなぎたいコンピュータ。 一般的には家庭にあるＰＣのブラウザがクライアントとなります。 以下の図中ではこれを[ク] と記載します。 サーバ： 一般的にサーバとは単体で使うことを目的とせず、他の利用者や コンピュータにサービスを提供するコンピュータのことです。 ここでは、httpsでの通信を提供しているコンピュータを指し、 多くの場合、ブラウザでアクセスする先のWebサイトとなります。 以下の図中ではこれを[サ] と記載します。 httpsでご挨拶が終わり、どんな暗号方式を使うのかといった やりとりが終わると、次にサーバからサーバ証明書がクライアント に送られます。 そのやりとりはものすごくシンプルで、サーバからクライアントに ServerCertificateというメッセージを送るだけです。 サーバ証明書を受け取ったクライアント側は、その内容が正しいか どうかを検証します。 3. サーバ証明書 －－－－－－－－ サーバ証明書というのは、要は電子証明書です。 電子証明書については、httpsその７～１０の４回に分けて解説 しました。 とまあ、マジメに書くと４回分位になるややこしいものですが、 端的に書くと、「サーバ側から伝えたい情報（公開鍵やURLなど）に 対して、証明機関という民間の組織が「署名」という行為を行って 作られた小さなデータ」です。 公開鍵ってナニ？とか証明機関ってナニ？署名って？という方は 以下のバックナンバーをご覧ください。 httpsその５（公開鍵暗号方式１） https://archives.mag2.com/0001678731/20181112064000000.html httpsその６（公開鍵暗号２） https://archives.mag2.com/0001678731/20181119064000000.html httpsその７（電子証明書１） https://archives.mag2.com/0001678731/20181126064000000.html httpsその８（電子証明書２） https://archives.mag2.com/0001678731/20181203064000000.html httpsその９（電子証明書３） https://archives.mag2.com/0001678731/20181210064000000.html httpsその１０（電子証明書４） https://archives.mag2.com/0001678731/20181217064000000.html ちなみに「がんばりすぎないセキュリティ」ではバックナンバーは 全て公開しています。 ホントは１年以上前の情報は古すぎて時代に合わない可能性が高く なるため、古い記事は非公開としたいところですが、そういうこと はできませんので、全公開としています。 さて、サーバ証明書というのは、形式は上述のとおり電子証明書 そのものです。 その中には、 １）サーバが使う公開鍵暗号の公開鍵 ２）サーバが自己申告する情報 ３）上記の２つが改竄（かいざん）されていないことの署名 ※署名とは、手書きのサインのことではなく、特定の計算を 行った値のことです。 の３つのデータが入っています。 サーバ証明書の検証とは、サーバが自己申告する情報を検証する ことに他なりません。 4. サーバが自己申告する情報の検証 －－－－－－－－－－－－－－－－－ さて、サーバが自己申告する情報は以下が典型的です。 １）サーバの所属する組織名 ２）サーバのドメイン名 また、証明機関が付加した以下の情報も検証に使います。 １）サーバ証明書を発行した証明期間名 ２）サーバ証明書の署名 ３）サーバ証明書の有効期間 確認することはいろいろありますので、順に説明します。 なお、それぞれの詳細な解説は上述のバックナンバーで行って いますので、そちらをご参照ください。 5. 証明機関の確認 －－－－－－－－－ 最初にクライアントが知っている証明機関かどうかを確認します。 各ブラウザにはあらかじめ、著名な証明機関の証明書（ルート証明 書またはルートCA証明書）が組み込まれています。 ここに含まれていない証明機関による署名が付いている場合は、 そのままでは信頼して良いのかどうかが判断できませんので、通常 は「信頼できない証明書です」といったエラーになります。 ここで問題がなければ、次の署名の確認を行います。 6. 署名の確認 －－－－－－－ 署名の正しさを確認する方法については、電子証明書の解説で書き ましたが、おさらいしておきます。 証明書はデータ部と署名部の二部構成となっています。 署名部にはデータ部を特定の方法でかきまぜてハッシュ値という値 を求め（ハッシュ関数というもので生成します）それを証明機間の 秘密鍵で暗号化したデータが入っています。 データ部を変更した時は、署名も変更が必要です。 データ部は誰でも変えられますが、署名には証明機関の秘密鍵が 要りますから、証明機関でないと変えられません。 ですから、署名が正しければデータ部が変更されていないと言える わけです。 署名を確認する方法ですが、署名を作る時と同じ方法でハッシュ値 を得ます。 次にサーバ証明書にある署名を証明機関の公開鍵（これはあらか じめブラウザに登録されています）を使って暗号を解きます。 この両者が一致していれば、データ部が改竄されてないと言える というわけです。 署名が一致しなければ、証明書として信頼できませんから、https としての通信は行えません。 ブラウザでは「不適切な証明書です」といったエラーとなります。 署名が確認できれば、次はサーバが自己申告した情報の確認を行い ます。 もう少しサーバ証明書の確認については解説することがあるの ですが、さすがに長くなってきましたので、途中ですが、今回は ここまでといたします。 次回はこの続きと、クライアント証明書の解説をします。 次回もお楽しみに