HTTPSで通信が暗号化されていても、相手の説明まで正しいとは限らないんだ。証明書が確かめる範囲を、一緒に見ていこう🐾
1. 証明書は何を確認するのか
TLSのサーバー証明書には、対象のドメイン名や公開鍵、有効期間などが記され、認証局（CA）が電子署名を付けます。PKI（公開鍵基盤）は、証明書の発行・検証・失効などを通して、公開鍵とその利用者の結び付きを扱う仕組みです。
Webで広く使われるDV（ドメイン認証）証明書では、発行時に申請者が対象ドメインを管理していることを確認します。企業の実在性や商品の品質、サイトの内容が正しいことまで保証するものではありません。組織の情報も確認する証明書がありますが、それでもサイトの善良さを保証するわけではありません。
偽サイトにも正規の証明書は発行され得ます。攻撃者が自分で管理する、正規サイトに似た別のドメインの証明書を取得することと、他人のドメインの証明書を不正に取得することは別の問題です。HTTPSの表示だけで、アクセス先を信頼しないことが大切です。
2. ブラウザがたどる証明書チェーン
証明書チェーンは、サーバー証明書から中間認証局の証明書を経て、ブラウザやOSが信頼するルート認証局へとつながります。ルートを信頼する判断は、署名を計算するだけで自動的に生まれるものではなく、ブラウザやOSの信頼ストアなどに基づきます。
- アクセス先のホスト名が、証明書の対象名と一致するか確認します。
- 証明書の署名、有効期間、用途や認証局の制約などを検証します。
- 信頼するルートまでチェーンを構築できるか確認します。
- 失効情報やCTなど、実装が採用する追加のポリシーも適用します。
TLSのハンドシェイクでは、サーバーが証明書の公開鍵に対応する秘密鍵を持っていることも確認します。証明書をコピーして表示するだけでは、正規のサーバーになりすますことはできません。
3. 認証局の侵害と対策
2011年のDigiNotar事件では、認証局への侵入によって不正な証明書が発行されました。Mozillaなどは、その認証局への信頼を取り消す対応を行いました。これは、暗号の計算が正しくても、発行の手続きや認証局の運用が侵害されれば問題が起こる例です。
PKIでは、役割の異なる対策を組み合わせます。どれか1つで不正発行をすべて防げるわけではありません。
- CAA：ドメイン管理者が、証明書の発行を許可するCAをDNSで指定します。CAが発行前に確認するための仕組みであり、規則を無視するCAや、侵害された許可済みCAによる不正発行まで暗号学的に阻止するものではありません。
- Certificate Transparency（CT）：証明書の発行を公開ログで監視・監査しやすくします。Chromeなどは対象となる公開信頼された証明書にCTポリシーを適用します。世界中のすべての証明書に一律に適用される規則ではなく、ログへの記録自体が不正を止めるわけでもありません。
- 失効への対応：CRLは失効した証明書のリスト、OCSPは証明書の状態を問い合わせる仕組みです。ブラウザ独自の配布方式もあり、ChromeのCRLSetsは全証明書の失効状態を毎回問い合わせるOCSPの代用品ではありません。確認方法や通信できない場合の扱いは実装によって異なります。
4. 暗号化・認証・内容の信頼性を分ける
暗号化は通信内容を守り、証明書は接続先と公開鍵の結び付きを確かめるために使います。その先にある説明や商品を信頼できるかは、別に判断する必要があります。証明書エラーが出た場合は、確認せずに警告を無視して進まないことも大切です。
ブロックチェーンは、参加者が記録の順序などについて合意する仕組みです。Webのドメインと公開鍵を結び付けるPKIとは目的が異なり、PKIをそのまま置き換える技術ではありません。Bitcoinの提案は2008年で、2011年のDigiNotar事件を受けて生まれたものでもありません。
「何が確認できたのか」を分けると、仕組みが見えてくるね。証明書の役割と限界を知ることが、通信を理解する手がかりになるよ🐾