届いた公開鍵は、本当にその店のもの？ 証明書と認証局、証明書の連鎖から、TLS の CertificateVerify、ドメイン認証と ACME、Certificate Transparency、短くなる有効期間まで、鍵マークの意味を図の動きでたどります。
前の章では、電子署名を検証すれば「この署名は、その公開鍵に対応する秘密鍵で作られた」ことが分かると見ました。けれども、その公開鍵が本当に相手のものかどうかは、署名だけでは決まりません。この章は、その残った問いに答えます。
アオイがブラウザで https://shop.example を開くと、店のサーバーから公開鍵が届きます。第5章で見た TLS 1.3 の流れでは、この公開鍵を手がかりに相手を確かめ、暗号化された通信が始まります。
ところが、通信の途中になりすます人が割り込んで、自分の公開鍵を送ってきたらどうでしょう。図の二つの青い鍵は、どちらもただの数の並びです。公開鍵そのものには「shop.example のもの」という名前が書いていないので、見た目では区別がつきません。なりすます人の鍵を信じてしまえば、暗号の計算は正しく働いたまま、話し相手だけがすり替わります。
必要なのは、「この名前の持ち主の公開鍵はこれです」と、信頼できる誰かが保証した書類です。
証明書（正式には X.509 公開鍵証明書）は、「この名前の公開鍵はこれです。この日まで有効です」と書いた小さなデータです。図では、さきほどの青い公開鍵が黄色いカードの中に入り、その上に名前 shop.example、下に有効期限と発行者が並びました。証明書の形式は RFC 5280 で決められています。
身近なたとえは、役所が発行する身分証明書です。身分証は「この顔写真の人は、この名前の人です」と、名前と本人を結びつけます。証明書は同じように、名前（ドメイン）と公開鍵を結びつけます。
ただ、こういう書類を作るだけなら誰にでもできます。なりすます人も「名前：shop.example」と書いて、自分の公開鍵を入れたカードを作れてしまいます。身分証に役所の印や偽造防止の加工があるように、証明書にも「誰が保証したのか」と「中身が書き換えられていないこと」を示す仕組みが要ります。それが次のページの、認証局の電子署名です。
証明書を保証する役目を負うのが認証局（Certificate Authority、略して CA）です。店は自分のドメイン名と公開鍵を認証局に届け出ます。認証局は確認を済ませると、証明書の中身（名前・公開鍵・有効期限など）に、自分の秘密鍵で電子署名をします。図では、右上の認証局の赤い秘密鍵から紫の署名が飛んできて、証明書のカードに付きました。
前の章で見たとおり、署名した中身を一文字でも変えると、検証に通らなくなります。なりすます人が名前や公開鍵を自分の都合のよいものに書き換えれば、認証局の署名が合わなくなります。認証局の秘密鍵を持たないので、書き換えた中身に合う新しい署名も作れません。
身分証のたとえでいえば、署名は役所の印にあたります。ただ、たとえには限界があります。身分証は人が目で見て確かめますが、証明書の署名はプログラムが数学的に検証します。また、認証局は役所ではなく、主に民間の会社や団体で、世界にたくさんあります。どの認証局を信じるかは、この先のページで見るように、OS やブラウザがあらかじめ決めています。
TLS の接続が始まると、サーバーは公開鍵だけでなく、証明書を丸ごと送ってきます。ブラウザは証明書に書かれた発行者を見て、その認証局の公開鍵で署名を検証します。図では、証明書のカードが店からアオイの側へ移り、左下の青い「CA の公開鍵」から紫の署名へ矢印が伸びて、緑の「署名 OK」が付きました。
署名が通れば、ブラウザは二つのことを知ります。この証明書はその認証局が発行したものであること、そして発行されてから中身が書き換えられていないことです。こうして「shop.example の公開鍵はこれ」という結びつきを、認証局の保証つきで受け取れます。
ただ、ここで疑問が一段上に移っただけだと気づいたかもしれません。ブラウザが使った「CA の公開鍵」は、本当にその認証局のものでしょうか。それを確かめるには、また別の証明書が必要になりそうです。この問いをどこで終わらせるのかが、次のページの証明書の連鎖です。
答えは、CA の公開鍵もまた証明書に入れて、さらに上の認証局に署名してもらうことです。実際の HTTPS では、店の証明書（サーバー証明書）に署名しているのは中間 CA と呼ばれる認証局で、中間 CA の証明書にはルート CA が署名しています。図では左から順に、サーバー証明書、中間 CA の証明書、ルート CA の証明書が並びました。前のページの「CA の公開鍵」は、まん中のカードに収まっています。
ブラウザは、右の証明書に入っている公開鍵で、左の証明書の署名を検証します。中間 CA の公開鍵でサーバー証明書の署名を、ルート CA の公開鍵で中間 CA の証明書の署名を確かめていくわけです。鎖を一つずつたどり上がるので、これを証明書の連鎖（証明書チェーン）と呼びます。サーバーは接続のときに、自分の証明書と中間 CA の証明書をまとめて送ります。
間に一段はさむのは、ルート CA の秘密鍵を守るためです。この鍵が盗まれると被害がとても大きいので、ふだんは厳重に保管して、めったに使いません。日々の発行は中間 CA の鍵で行い、もし中間 CA に問題が起きても、その中間 CA だけを無効にすれば済むようにしています。
鎖をたどり上がると、最後はルート CA の証明書に着きます。ルート CA の証明書は、ルート CA が自分の秘密鍵で自分に署名したもので、自己署名の証明書と呼ばれます。自分で自分を保証しているだけなので、署名を検証できても、それだけでは信じる理由になりません。
そこで、信じてよいルート証明書の一覧を、OS やブラウザがあらかじめ持っています。これをトラストストアと呼びます。図の右の灰色の枠がトラストストアです。緑の枠が左端から右端のルート証明書へ移り、三枚の証明書に順にチェックが付きました。たどり着いたルート証明書がこの一覧に入っていれば、ブラウザは鎖全体を信頼します。
一覧に入れるかどうかは、OS やブラウザを作る会社や団体が、認証局の運用の監査結果などをもとに決めています。つまり私たちは、ふだん意識しないまま、この一覧を作った人たちの判断を信じていることになります。会社が配るパソコンなどでは独自のルート証明書が足されていることがあり、その場合はそのルートで発行された証明書も信頼されます。
署名の鎖がつながっても、まだ確かめることがあります。ブラウザが証明書について見るのは、主に図の右の四つです。前のページのチェックが、この一覧へ移ってきました。
一つめは、署名の連鎖がトラストストアのルートまでつながること。二つめは名前です。証明書には、その証明書を使ってよいドメイン名が SAN（Subject Alternative Name、別名の欄）に書いてあり、ブラウザはアオイが開いた shop.example がそこに含まれるかを比べます。正規の認証局が発行した本物の証明書でも、書いてある名前が other.example なら通りません。三つめは、いまが有効期限の内側にあることです。
四つめは、証明書が失効していないこと。秘密鍵が漏れたなどの理由で、期限より前に無効にされることを失効といいます。認証局は失効した証明書の一覧（CRL）を公開し、一枚ずつ問い合わせに答える仕組み（OCSP）もあります。ただ OCSP は、問い合わせからどのサイトを見ているかが認証局に伝わってしまうため、Let's Encrypt は2025年に OCSP をやめて CRL に一本化しました。ブラウザ各社は、失効の情報をまとめて配る独自の仕組みも使っています。
四つのうちどれかが欠ければ、ブラウザは警告の画面を出して接続を止めます。
ここまでで、証明書が本物かどうかは確かめられるようになりました。けれども、証明書は配ってよい公開の情報です。サーバーは接続してきた誰にでも同じ証明書を送るので、なりすます人も簡単にコピーを手に入れられます。証明書を持っているだけでは、相手が本物の店だという証拠になりません。
本物の店にだけできるのは、証明書の公開鍵に対応する秘密鍵を使うことです。TLS 1.3 では、サーバーは証明書を送ったあと、それまでのやり取りの内容に自分の秘密鍵で署名し、CertificateVerify というメッセージで送ります（RFC 8446 の 4.4.3 節）。図では、右上の店の赤い秘密鍵で「この接続のやり取り」に署名し、紫の署名がアオイへ届きました。
ブラウザは、左下の証明書に入っている公開鍵でこの署名を検証します。署名の対象には、ブラウザがこの接続のために選んだ乱数や鍵共有の値が含まれるので、ほかの接続で使われた署名を持ってきても通りません。緑の「署名 OK」が付いたとき、ブラウザは「いま話している相手は、shop.example の証明書の秘密鍵を持っている」と分かります。
今度は、なりすます人が通信の途中に割り込んだ場合です。なりすます人は、店の本物の証明書をコピーしてアオイに送ります。図では、証明書のコピーがなりすます人の手元へ移りました。証明書そのものは本物なので、署名の連鎖・名前・期限・失効の四つの確認はすべて通ってしまいます。
ところが、次の CertificateVerify で行き詰まります。この接続のやり取りに署名するには店の秘密鍵が要りますが、秘密鍵は店のサーバーの外に出ていません。なりすます人が自分の秘密鍵で署名しても、証明書に入っている店の公開鍵では検証に通りません。図の左下の印が、緑の「OK」から赤の「NG」に変わりました。ブラウザはここで接続を打ち切ります。
裏を返せば、証明書の仕組みが守ってくれるのは、サーバーの秘密鍵が漏れていない間です。秘密鍵が盗まれれば、なりすます人は本物と区別のつかない署名を作れます。だから秘密鍵が漏れたときは、証明書を失効させ、新しい鍵ペアで証明書を取り直します。
認証局は、申し込んできた人の言うとおりに証明書を出すわけではありません。いちばん広く使われているドメイン認証（DV）の証明書では、申し込んだ人が「そのドメインを実際に管理していること」を確かめます。
無料で証明書を発行する Let's Encrypt は、この確認を ACME という手順（RFC 8555）で自動にしています。店のサーバーで動くプログラムが証明書を申し込むと（図の①）、認証局は確認用の文字列を渡します（②）。プログラムはその文字列を shop.example の決まった場所に置き（右下）、認証局はそこを外から見に行きます（③）。指定どおりの文字列が見つかれば、このドメインを管理している人の申し込みだと判断して、証明書を発行します（④）。DNS の設定に文字列を書いて示す方法もあります。
ここから分かるように、DV が保証するのは「ドメインの管理者であること」までです。会社の実在まで確かめる種類の証明書（OV・EV）もありますが、いまの主なブラウザは表示の上で区別しません。鍵マークが伝えるのは「通信相手はそのドメインの持ち主で、通信は暗号化されている」ということです。偽の店が自分で取ったドメイン shop-example.net にも、同じ鍵マークは付きます。
認証局が間違えたり、侵入されたりして、本来の持ち主ではない人に証明書を出してしまうことがあります。2011年にはオランダの認証局 DigiNotar が侵入され、google.com などの偽の証明書が発行されました。認証局の署名が付いている以上、ブラウザだけでは本物と見分けられません。
そこで生まれたのが Certificate Transparency（CT、証明書の透明性）です。認証局は発行する証明書を、誰でも読める公開のログに登録します。ログは追記しかできない作りで、あとから記録をこっそり消せません。登録すると「ログに記録した」という印（SCT）がもらえ、主なブラウザは、この印のない証明書を受け入れません。図では、認証局の証明書が中央のログに載り、左下のアオイのブラウザに記録済みの印が届いています。
ログは誰でも見張れるので、ドメインの持ち主は、自分のドメイン名で身に覚えのない証明書が出ていないかを調べられます。右上の監視する人が、赤い「身に覚えのない発行」を見つけました。CT は誤発行そのものを止める仕組みというより、隠せなくする仕組みです。見つかれば、その証明書の失効や、認証局への処分につながります。仕様は RFC 9162 にあります（いま広く使われているのは、最初の版の RFC 6962 の形式です）。
証明書の有効期間は、ここ数年で大きく短くなっています。ブラウザ各社と認証局が決まりを話し合う CA/Browser Forum は、2025年に、サーバー証明書の最長の有効期間を段階的に縮めることを決めました。それまでの最長は398日でしたが、2026年3月15日以降に発行する証明書は200日まで、2027年3月15日からは100日まで、2029年3月15日からは47日までになります（Baseline Requirements の 6.3.2 節）。図の棒が、その段階を上から順に表しています。2026年11月のいまは、200日の段階です。
短くする理由の一つは、失効の仕組みに頼りきれないことです。失効の情報がすべてのブラウザに確実に届くとは限りません。期限そのものを短くしておけば、漏れた鍵や古くなった確認結果が使われ続ける期間を限れます。ドメインを手放した人の証明書が長く残る、といったことも減ります。
その代わり、証明書を人の手で更新するのは現実的でなくなっていきます。前のページで見た ACME のような自動の更新が、前提になりつつあります。
この章では、「その公開鍵は、本当に相手のものか」という問いに答えてきました。証明書は、名前と公開鍵と有効期限を一枚にまとめ、認証局が署名したものです。ブラウザは証明書の連鎖をトラストストアのルートまでたどり、名前・期限・失効を確かめます。さらに TLS では、サーバーが証明書の公開鍵に対応する秘密鍵で CertificateVerify に署名して、自分がその鍵の持ち主であることを示します。
では、鍵マークが付いていれば、そのサイトは安全なのでしょうか。鍵マークが保証するのは、いま話している相手がアドレス欄のドメインの持ち主であること、そして通信が暗号化され、途中で読まれたり書き換えられたりしないことです。その店が誠実に商売をしているか、そのドメインが自分の行きたかった店のものかは、証明書が答える範囲の外にあります。偽の店も自分のドメインで証明書を取れば、同じ鍵マークが付きます。Chrome が2023年に鍵マークを別のアイコンに替えたのも、鍵が「安全なサイト」の印だと誤解されやすかったからです。つまり鍵マークが示すのは「相手と通信路の確かさ」で、「サイトの中身の確かさ」ではありません。
証明書は、署名を付けたデータで「誰の何か」を運ぶ仕組みでした。次の章では、同じように署名を付けてログインの情報などを運ぶ JWT を見ていきます。
