SSL/TLSとサーバー証明書・クライアント証明書をゼロから理解する

まずは銀行のサイトで考える

スマートフォンで銀行のサイトを開き、残高を確認するとします。ここで心配なのは3つ。①偽の銀行に接続していないか、②残高や暗証情報を盗み見られないか、③送金先を書き換えられないか、です。

これらをまとめて実現するのがHTTPSで使われるTLSです。証明書が暗号化そのものをするわけではありません。証明書は主に「誰の公開鍵か」を確かめる材料です。

言葉の全体像：何が何を担当するのか

鍵には3つの仕事がある

「鍵」とひとことで言っても、登場する鍵は一種類ではありません。ここを分けると急に分かりやすくなります。

たとえばレストランで「店員の身分確認」「お互いの合言葉決め」「合言葉を使った秘密の会話」が別の手順であるのと同じです。

サーバー証明書は「この公開鍵はこのサイトのもの」という説明書

ブラウザが https://bank.example に接続すると、サーバーは自分の証明書を提示します。証明書には、対象のドメイン名（通常はSAN）、公開鍵、発行元、期限、用途などの情報が入っています。秘密鍵は含まれません。

ここで2種類の署名を区別しましょう。認証局による証明書への署名は「この証明書の内容を発行元が保証した」ことを示します。一方、サーバーの秘密鍵によるハンドシェイク署名は「目の前の通信相手が、証明書の公開鍵に対応する秘密鍵を持っている」と示します。役割が違います。

認証局は何をしている？

誰でも「私は銀行です」と書かれた自称の証明書は作れます。それだけでは信用できません。そこで信頼できる認証局（CA）が、証明書の内容を確認したうえで署名します。ブラウザは信頼するルートCAをあらかじめ保持し、サーバー証明書までの署名のつながりを検証します。

ただし「CAが署名した」だけで十分ではありません。アクセスしたドメイン名と一致するか、有効期限・鍵用途・失効情報など、適用される検証条件も確認します。鍵マークは銀行の経営の健全性やWebページの内容の安全性まで保証しません。

HTTPSでは実際に何が起こる？

代表例として、証明書でサーバーを認証するTLS 1.3の通常の新規接続を追ってみます。実際には通信の往復や暗号化開始のタイミングなどが細かく定められていますが、ここでは役割ごとに整理します。

公開鍵は暗号化用？署名用？

答えは「公開鍵暗号技術には両方の用途がある。ただし、同じ鍵・同じ方式を何にでも使うわけではない」です。代表例を区別しましょう。

ここでの鍵交換は、公開鍵でメッセージを暗号化して渡す操作とは異なります。ECDHEは両者が独立に計算して同じ共有秘密を得る鍵合意です。ECDSAやEd25519は署名方式であり、公開鍵暗号の暗号化方式ではありません。

クライアント証明書は何のため？

ふつうのHTTPSでは、ブラウザが「訪問先のサーバー」を確認します。一方、会社の経費精算システムでは「このアクセス元は会社が認めた端末か」も確認したいことがあります。そこでクライアント証明書を使います。

社員証を見せるだけなら写真をコピーできるかもしれません。しかしTLSでは証明書ファイルを持っているだけでなく、対応する秘密鍵で実際に署名できることが必要です。秘密鍵はOSの保護領域やスマートカード、TPMなどに保管されることがあります。

操作して確かめる：どの確認が失敗すると止まる？

以下では「サーバー証明書の名前を不一致にする」「認証局を信頼できなくする」「社員PCの証明書をなくす」などを切り替えてみてください。さらに、署名用公開鍵と通信の共通鍵の役割を切り替えると混同しにくくなります。

全部の技術を一枚で整理する

ここだけは混同しない

まとめ：「相手確認」「合言葉づくり」「秘密の会話」を分ける

認証局は身分証の発行者、証明書は公開鍵つきの身分証、電子署名は秘密鍵の持ち主による証明、鍵交換は通信のための秘密づくり、共通鍵暗号は実際の会話の保護です。HTTPSはこれらを組み合わせる仕組みです。クライアント証明書を追加すると、サーバー側も接続元の鍵所有者を確認できます。