「TLS証明書って、結局なに？ なんで期限が切れると、サイトが開かなくなるの？」。情シスをやっていると、こんな質問を、一度は受けたことがあるはずです。答えられるつもりでも、いざ説明すると、「ルート？ 中間？ サーバー？ 結局どれのこと？」と、相手の顔が曇ってしまう。説明する側もつらいところです。
先日のeMudhraの中間証明書8件が漏洩した問題も、社内で説明してもなかなか理解してもらえないです。同じ情シス部門のメンバーや開発者も理解してもらえないことがあります。（僕の説明が悪いだけかもしれませんが）
そこで復習も含めてルート証明書、中間証明書（中間CA証明書）、サーバー証明書、認証局など証明書周りについて分かりやすく解説したいと思います。
そこで、このシリーズ「TLS証明書の基礎」は、全4回で、証明書まわりの言葉と仕組みを、図を使って整理します。第1回の今回は、いちばん土台になる話です。TLS証明書とは何か、なぜ必要なのかを、身分証明書にたとえて説明します。
TLS証明書の結論：サイトの「身分証明書」で、通信の安全の土台
先に結論です。
| 項目 | ひとことで |
|---|---|
| TLS証明書とは | 「このサイトは、本物です」と、第三者が保証した、サイトの身分証明書 |
| 何を守る | ①盗聴されない ②書き換えられない ③相手が本物かを確かめられる |
| 誰が保証する | 認証局（CA）という、信頼された機関 |
| 証明書の中身 | 持ち主の名前、持ち主の公開鍵、有効期限、発行者の名前、発行者の署名 |
TLS証明書が必要な理由：ネットの通信は、途中で見られうる
ネットの通信は、手紙のようなものです。あなたのブラウザからサイトのサーバーまで、いくつもの機器（Wi-Fiのアクセスポイント、ルーター、プロバイダーの設備など）を通って届きます。その途中に、悪意のある人がいると、次の3つの問題が起きえます。
| 問題 | 何が起きる | 例 |
|---|---|---|
| 盗聴 | 通信の中身をのぞかれる | ログインのパスワードを、のぞき見される |
| 改ざん | 通信の中身を書き換えられる | 送金先の口座番号を、書き換えられる |
| なりすまし | 偽のサイトが、本物のふりをする | 銀行そっくりの偽サイトに、パスワードを入れてしまう |
この3つを防ぐ仕組みが、TLS（ティーエルエス）です。HTTPSの「S」にあたる部分で、通信を暗号化します。
暗号化の基本：公開鍵と秘密鍵のペア
TLSの暗号化には、「公開鍵」と「秘密鍵」というペアの鍵が出てきます。ここは、南京錠と鍵にたとえると分かりやすいです。
| 鍵 | たとえ | 役割 |
|---|---|---|
| 公開鍵 | 開いた状態の南京錠。誰に配ってもよい | 相手に渡して、「これで、私宛の情報をロックしてください」と頼む |
| 秘密鍵 | その南京錠を開けられる、たった1本の鍵 | 持ち主だけが持つ。これで初めて、中身を取り出せる |
サーバーは、公開鍵を世界中に配って、秘密鍵は自分だけで守ります。こうすると、途中で情報を見られても、秘密鍵がなければ、中身は読めません。
暗号化だけでは足りない：「相手が本物か」を、どう確かめる？
ここで、1つ問題が残ります。暗号化の相手が、偽物だったら、どうなるでしょうか。
偽のサイトが、「僕の公開鍵です」と、自分の南京錠を渡してきたら、あなたは、その南京錠で、パスワードをロックして送ってしまいます。暗号化は、きちんと働くのに、相手が悪い人、という最悪の状況です。
そこで必要になるのが、「この公開鍵は、確かに、このサイトのものです」と、第三者が保証してくれる仕組み。それが、TLS証明書です。
TLS証明書の中身：身分証明書にたとえる
TLS証明書は、身分証明書（たとえば運転免許証）に、よく似ています。
| 身分証明書の項目 | TLS証明書で対応するもの |
|---|---|
| 氏名 | サイトの名前（ドメイン名。例: example.com） |
| 顔写真（本人の特徴） | 持ち主の公開鍵 |
| 有効期限 | 証明書の有効期限 |
| 発行した機関（公安委員会など） | 発行した認証局（CA）の名前 |
| 偽造防止の印・ホログラム | 認証局のデジタル署名 |
デジタル署名は、「発行した機関が、確かに、この内容で認めました」という、改ざんできない印です。証明書の内容を、1文字でも書き換えると、署名が合わなくなるので、すぐに偽物だと分かります。
認証局（CA）とは：身分証を発行する、信頼された機関
証明書を発行するのが、認証局（CA：Certificate Authority）です。免許証を発行する公安委員会のような役割で、申込者が、本当に、そのドメインの持ち主かを確かめてから、証明書を発行します。
ブラウザやOSは、「この認証局なら信頼できる」というリストを、最初から持っています（これを信頼ストアといいます。詳しくは第2回です）。そのリストにある認証局が発行した証明書なら、ブラウザは、「本物だ」と判断します。
「SSL証明書」と「TLS証明書」：呼び方の違い
よく聞く「SSL証明書」と、「TLS証明書」は、同じものを指します。SSLは、TLSの前身にあたる、古い名前です。今、実際に使われているのは、TLSですが、「SSL証明書」という呼び方が、習慣として残っています。この記事では、TLS証明書と書きます。
証明書の種類：どこまで確かめたか
証明書には、発行のときに、どこまで確かめたかによって、3つの種類があります。
| 種類 | 確かめること | 特徴 |
|---|---|---|
| DV（ドメイン認証） | ドメインの持ち主であること | 自動で、すばやく発行できる。無料の証明書の多くはこれ |
| OV（組織認証） | ドメインに加えて、組織が実在すること | 証明書に、組織名が入る |
| EV（拡張認証） | 組織の実在を、より厳格に確認 | 審査が厳しい |
どの種類でも、通信の暗号化の強さは、同じです。違うのは、「持ち主を、どこまで確かめたか」です。
自分で確かめてみる：サイトの証明書を見るコマンド
実際のサイトの証明書は、コマンドで見られます。Git BashなどでOpenSSLが使える環境なら、次のとおりです。
# サイトの証明書から、持ち主・発行者・有効期間を表示する
echo | openssl s_client -connect gadgetzine.blog:443 -servername gadgetzine.blog 2>/dev/null | openssl x509 -noout -subject -issuer -dates
このブログ（gadgetzine.blog）で実行した結果（2026年10月30日に確認）は、次のとおりです。
subject=CN=gadgetzine.blog
issuer=C=US, O=Google Trust Services, CN=WE1
notBefore=Oct 27 01:13:14 2026 GMT
notAfter=Jan 25 02:13:11 2027 GMT
| 行 | 意味 |
|---|---|
| subject | 持ち主。ここでは、gadgetzine.blog |
| issuer | 発行者。ここでは、Google Trust Servicesの「WE1」 |
| notBefore / notAfter | 有効期間。約3か月（90日）です |
有効期限が、約3か月と短いのは、今の証明書の流れです。期限が短いほど、万が一、秘密鍵が漏れても、被害の期間が限られます。そのかわり、更新を自動化していないと、期限切れで、サイトが開かなくなるので、注意が必要です。
あるある：証明書の更新を、「あとで」にしてしまう
最後に、情シスの「あるある」を1つ。証明書の期限が近づいて、メールの通知が届く。でも、今日は忙しいので、「あとで」。そして、期限の朝、サイトが開かなくなって、問い合わせが殺到する。
ごはんにたとえるなら、賞味期限のシールを、見ないふりして、冷蔵庫に入れっぱなしにしているようなものです。期限は、見つけたときに、予定に入れる。自動更新にできるものは、自動更新にする。これが、鉄則です。
今回のまとめと次回予告
| 項目 | 内容 |
|---|---|
| TLS証明書 | サイトの身分証明書。第三者（認証局）が保証する |
| 守るもの | 盗聴・改ざん・なりすましを防ぐ土台 |
| 中身 | 名前・公開鍵・有効期限・発行者・デジタル署名 |
| 種類 | DV・OV・EV。暗号化の強さは同じで、確認の深さが違う |
次回は、「ルート証明書」「中間証明書」「サーバー証明書」の3つの関係を、図で整理します。同じ「証明書」という名前なのに、なぜ3種類もあるのか、がすっきり分かります。
ほかのセキュリティの話題は、当ブログの技術ネタからどうぞ。
参考
ITもごはんも、腹八分目が長続きのコツ！
コメント