以下は、某メルマガに書いた記事です。
オリジナルはこちら
httpsのプロトコル（通信手順）解説の３回目です。
今回はサーバ証明書の検証手順やクライアント証明について解説しています。
今回もお楽しみください。
今回は、httpsの通信手順（プロトコル）解説の３回目となります。 前回の繰り返しですが、通信手順といっても難しいことをやるわけ ではありません。コンピュータ同士でのチャットのようなものです。 チャットと言ってわかりにくければ携帯電話のショートメッセージ による会話と言えばイメージしやすいでしょうか。 そのチャットを通してお互いに必要な情報をやりとりします。 httpsの場合であれば、「あんただれ？」とか「俺は暗号方式○○ か△△が使えるんだけど、そっちは？」などというやりとりを するわけです。 これを専門用語ではプロトコルと呼んでいるにすぎません。 さて、前回はサーバから送られてきたデータを検証する内容の途中 でしたので、その続きからとなります。 なお、この記事では、証明機関・サーバ証明書・署名といった用語 を説明なく使っています。 この連載の以前の記事（httpsその１～その１０）ではこういった 用語についても詳しく解説していますので、未読の方はそちらに目 を通してから読んでいただければ、わかりやすいかと思います。 1. TLSハンドシェイク（再掲載） －－－－－－－－－－－－－－－ 前回と同じ内容ですが、httpsでは次の順でやりとりを行います。 1. TLSハンドシェイク 1.1 ご挨拶 1.2 サーバ証明書の検証 1.3 （クライアント証明書の検証） 1.4 鍵交換 1.5 暗号化通信への移行 2. 暗号化した状態でのhttp このうち、「1.1 ご挨拶」を前々回に、「1.2 サーバ証明書の 確認」の一部を前回解説しました。 今回はその続きと、「1.3 （クライアント証明書の検証）」を解説 します。 2. サーバ証明書の検証 －－－－－－－－－－－ サーバ証明書はサーバが自己の身元保証のためにクライアント側に 送るデータです。 その内容はおおむね次の通りです。 １）サーバ証明書を発行した証明機関名 ２）サーバ証明書の署名 ３）サーバ証明書の有効期間 ４）サーバの所属する組織名 ５）サーバのドメイン名 このうち、１と２については前回のメルマガで解説しましたので 今回はその続きです。 3. サーバ証明書の有効期間の確認 －－－－－－－－－－－－－－－－ 次に、サーバ証明書の有効期間を確認し、現時点で有効かどうか を確認します。 有効期間内であっても、例えば秘密鍵が漏出してしまったなどの 理由で無効としたい場合がありますので、証明機関から失効した 証明書リストを取り寄せて確認を行います。 4. サーバのドメインの確認 －－－－－－－－－－－－－ 次に、アクセスしようとしているURLのドメイン名と実際のドメイン 名が合っていることを確認します。 ドメイン名というのは、サーバがどこにあるかを示す住所のような ものです。 例えば、次のようなURLを考えてみます。 https://example.com/index.html このうち、exmaple.com の部分がドメイン名になります。 サーバ証明書にはこのドメイン名が含まれています。 クライアントは、実際にアクセスしているURLとサーバ証明書の ドメイン名を比較し、一致していることを確認します。 実際にアクセスしても、証明書のドメインが食い違っていれば、 ヨソの証明書という意味ですから、全く信頼が置けません。 この場合は、「他のサイトの証明書です」といったエラーになり、 やはり通信は行われません。 さて、ここで注意していただきたいのは、以上の確認はあくまで 技術的に正しい証明書であることを証明しているに過ぎないこと です。 いくらサーバ証明書が正しくて、httpsとして正しくても、その サイトが善良であることなど証明できるはずがありません。 あくまで、サーバ証明書に書かれた内容と実際のサイトの情報が 一致していることを証明しているに過ぎません。 あたりまえですが、httpsだからといって接続先が善意のサイト とは限らないということです。 さて、以上の手続きに全て合格すれば晴れて証明書の確認が終わり です。 証明書の確認だけで、これだけのことを行わなければ安全は確保 できないんです。 httpsという仕組みが複雑になるのはこういった手間をかけないと 安全とは言えないからなんですね。 5. クライアント認証 －－－－－－－－－－ さて、ここまで説明してこなかったのですが、TLSハンドシェイク の表に、次のようなカッコ付きの行があります。 1.3 （クライアント証明書の検証） これがカッコ付きになっているのは、これがオプション機能で あまり使われていない機能だからです。 なので、ここでもサラリとだけ触れるに留めておきます。 これは、サーバ証明書とは全く逆に、クライアントの身元保証の 仕組みです。 例えば、重要な情報を保持しているページなどであれば、IDとパス ワード以外にも接続できるクライアントを限定したいケースがあり ます。 そのための方法としてhttpsではクライアント証明書を用います。 内容は、サーバ証明書とほぼ同じで、確認する内容も同様です。 ただ、クライアント側から提示して、サーバ側が検証するという 形になり、主従が入れ換わる形になります。 ただ、クライアント証明書というのはインストール作業が結構 難しく、一般の方には手に負えない場合が多いのです。 技術的には非常にスジの良い方式なのですが、活用するハードルが 高いため、あまり活用されていないのが実情です。 技術的に良いからといって広く利用されるとは限らない例と言え ます。 なお、httpsにこだわらなければ、他にも接続元を限定する方法は いろいろと存在しています。 今回はhttpsにフォーカスしていますので、ここでは触れませんが 機会があれば、別記事にて解説をしたいと思います。 6. 暗号化のための鍵交換（予告編） －－－－－－－－－－－－－－－－－ さて、ここまででTLSハンドシェイクのうち、以下の３つの 解説を行いました。 1.1 ご挨拶 1.2 サーバ証明書の検証 1.3 （クライアント証明書の検証） 後、大きなテーマとして残っているのは 鍵交換となります。 次回はこの鍵交換の具体的な方法と暗号化通信への移行に ついて解説をします。 長かったhttpsのシリーズですが、次回が最終回の予定です。 もう少しだけおつきあいください。 次回もお楽しみに。