CERTIFICATES · WEB TRUST
認証局（CA）と電子証明書とは？
Webサイトの「本物らしさ」を確かめる仕組み
ネット銀行のサイトを開くと「https://」と表示されます。でも、偽物のサイトだって鍵を作れます。ブラウザはどうやって、接続先の公開鍵を信用してよいか判断するのでしょうか。
ブラウザが確かめたいこと
アクセス先の名前
bank.example なのか
公開鍵の持ち主
サイト名と鍵の結び付き
信頼できる発行経路
信頼済みルートまで到達
1. 鍵を持っているだけなら偽物でもできる
誰でも「秘密鍵」と「公開鍵」のペアを作れます。攻撃者も同じです。したがって、あるWebサイトが公開鍵を見せてきただけでは、それが本物の銀行のものかどうかは分かりません。
本物の銀行を見たい
bank.example
名前と公開鍵のつながりを確認する必要がある。
見た目が似た偽サイト
bаnk.example
似ていても別の名前。HTTPS接続でも正規の銀行とは限らない。
上の偽サイトの例は、見た目が似た異なる文字を含む名前のイメージです。実際にはブラウザのURLを正確に確かめる必要があります。
2. 電子証明書は公開鍵の『身分証』
電子証明書には、対象の公開鍵、名前、発行者、有効期間、利用目的などの情報が入っています。そして認証局が、その情報に電子署名を付けます。
X.509 証明書のイメージ
- 対象（SAN）
- DNS:bank.example
- 公開鍵
- Webサーバの公開鍵
- 発行者
- Example Intermediate CA
- 有効期間
- 開始日時〜終了日時
- 署名
- 発行したCAの秘密鍵で作られた署名
3. 認証局（CA）は『鍵の保証人』
CA（Certification Authority）は、証明書に電子署名をして発行する主体です。Webサイトの運営者から発行を申請されると、証明書の種類に応じてドメイン名の管理権限などを確認します。
① 公開鍵を準備
サイト運営者が秘密鍵と公開鍵を準備し、証明書を申請する。
② 名前の管理権限を確認
CAが規定された方法でドメインに対する管理権限などを確かめる。
③ CAが証明書に署名
公開鍵と対象の名前などを含んだ証明書を発行する。
④ ブラウザが検証
署名と信頼の経路を確認して、公開鍵を採用できるか判断する。
CA自身も「誰が発行したCAなのか」という問題を抱えます。それを解決するための階層構造が、次の信頼の連鎖です。
4. ルートCA → 中間CA → Webサイト
多くの公開Web PKIでは、端末・ブラウザが信頼するルートCAから、証明書を発行する中間CAを経て、対象のサーバ証明書まで署名のつながりを検証します。
ルートCA（信頼の起点）
端末側で信頼することを決めている
中間CA
ルートCAなどの署名を検証
Webサイトの証明書
ドメイン名と公開鍵を結び付ける
最上位のルートは「自分が自分に署名したから信用する」のではありません。OSやブラウザなどの信頼ストアに、あらかじめ信頼の起点として登録されていることが重要です。
5. ブラウザは署名以外も確認する
証明書の署名だけ正しくても足りません。接続した名前に合っているか、期限内か、証明書の用途が正しいか、ルートへつながるか、失効などの扱いはどうかを合わせて評価します。
| 確認 | 具体例 | 失敗したら |
|---|---|---|
| 名前 | bank.example 用か | 別サイトの証明書かもしれない |
| 有効期間 | 期限内にあるか | 期限切れを受け入れない |
| 署名の連鎖 | 中間CAとルートの署名関係 | 発行経路を信用できない |
| 信頼の起点 | 信頼済みのルートか | 未知のルートをそのまま信じない |
| 用途・制約 | サーバ認証に使えるか | 用途が違えば拒否 |
| 失効状態 | 秘密鍵漏えいなどで失効していないか | 失効の確認方法・失敗時挙動は環境依存 |
6. 実験：証明書が期限切れなら？
「正常」「偽サイト名」「期限切れ」「知らない認証局」などの場面を切り替え、なぜ警告になるのか試してみましょう。
INTERACTIVE LAB
このサイトの証明書は信用できる？
銀行サイトにアクセスするつもりで、証明書のチェック項目を切り替えてください。
チェックリスト
信頼の連鎖
✓ 信頼ストアに登録
↓ 署名を検証
✓ 発行経路が有効
↓ 署名を検証
対象：bank.example
検証条件を満たす
ボタンで理由を確認できます。
簡略化した学習用モデルです。実際の証明書チェーン構築、TLSの署名検証、名前の照合規則、失効情報取得、ブラウザの失敗時動作は環境・ポリシーによって異なります。
7. HTTPSと認証局はどこで関係する？
HTTPSでは、ブラウザとサーバがTLSによって安全な通信路を作ります。サーバ認証の一般的な流れでは、ブラウザはサーバ証明書から公開鍵と名前・発行者の情報を確認し、TLSハンドシェイクの署名検証などを行います。
ここで大切なのは「証明書の検証」と「通信データの暗号化」は役割が違うことです。証明書は信頼できる鍵かを判断する材料です。通信の暗号化には、TLSの鍵共有などで得た対称鍵が使われます。
8. 電子署名と認証局は同じものではない
電子署名
文書や証明書に対して署名を作る技術
秘密鍵で作成し公開鍵で検証
認証局（CA）
名前と公開鍵の結び付きについて証明書を発行する主体
証明書に署名を付ける
電子証明書
公開鍵・名前・用途・発行者などを記載したデータ
検証可能な名前と鍵の結び付き
つまり「電子署名」は道具、「認証局」は発行・保証する主体、「証明書」は発行されたデータです。MACのような共通鍵の認証技術とも区別します。
9. 証明書があっても、危険なサイトは存在する
攻撃者が自分のドメインを取得し、そのドメインの管理権限を証明できれば、通常はそのドメイン用の証明書を発行してもらえます。HTTPSで暗号化されていても、そのサイトが詐欺サイトでないとは限りません。
対策として、リンクを開く前後にドメイン名を確認すること、突然のパスワード要求や振込先変更に注意すること、ブラウザの証明書エラーを安易に回避しないことが重要です。