TLSとは？「証明書を確認してから暗号通信を始める」仕組みをやさしく解説

2026年8月13日 20:05

Webサイトを開いた時、URLが「https://」で始まっていれば、通信にはTLSが使われています。しかし、「証明書」「公開鍵」「秘密鍵」「共通鍵」が一度に登場するため、仕組みが分かりにくく感じます。

結論から言うと、TLSは次の三つを実現する仕組みです。

HTTPSは「HTTPをTLSで保護した通信」と考えると分かりやすいです。

TLS通信は三段階で始まる

例として、ブラウザからWebサーバへ接続する流れを見てみます。

最初にブラウザは、対応できるTLSのバージョンや暗号方式などをサーバへ伝えます。サーバは、その中から利用する方式を選んで応答します。

この時点では、まだ本格的な暗号通信は始まっていません。安全な通信を始めるための準備段階です。

次にサーバは、サーバ証明書をブラウザへ提示します。証明書には、サイトのドメイン名、公開鍵、有効期限、発行者などが記録されています。

ブラウザは主に次の点を確認します。

この確認には、端末やブラウザが持つ「信頼できる認証局の一覧」が使われます。Javaアプリケーションから外部のHTTPS APIへ接続する場合は、Javaのトラストストアが同じような役割を担います。

証明書を見れば公開鍵は入手できますが、サーバだけが持つ秘密鍵は外部へ送られません。サーバは秘密鍵を使って通信開始時の情報に署名し、「この証明書の正当な所有者である」ことを証明します。

相手を確認した後、ブラウザとサーバは、やり取りした情報から同じ「共通鍵」を作ります。現在主流のTLSでは、共通鍵そのものをネットワークへ送るのではなく、双方が鍵交換用の情報を出し合って同じ秘密を計算します。

その後のWebページ、パスワード、APIのデータなどは、この共通鍵を使って暗号化されます。

なぜ公開鍵方式を通信全体に使わないのでしょうか。公開鍵暗号は本人確認や鍵交換に向いていますが、大量のデータ処理には負荷がかかります。一方、共通鍵暗号は高速です。そのためTLSでは、それぞれの長所を組み合わせています。

混乱しやすい点を、ひと言で整理すると次のようになります。

「サーバの秘密鍵でWebページ全体を暗号化している」と覚えるのは正確ではありません。少なくとも現在主流のTLSでは、秘密鍵は主にサーバの本人確認に使われ、実際の通信データは接続ごとに作られた共通鍵で守られます。

TLSの流れは、「相手を確認する→安全に共通鍵を作る→共通鍵でデータを守る」の順番です。

鍵や証明書を別々に暗記するより、「誰を信頼するのか」「どの鍵を何に使うのか」を通信の順番に沿って考えると、TLSの全体像が見えやすくなります。

HTTPSについて記事にしておりますので、こちらもご覧いただければ幸いです。