認証局とは
認証局（Certificate Authority／サーティフィケート・オーソリティ／CA・シーエー）は、公開鍵証明書へ電子署名し、ドメインや組織などの確認結果を保証する主体です。
WebのTLSでは、サーバーが提示した公開鍵とドメイン名の結び付きを証明書に記し、ブラウザーが信頼するCAの署名で検証できるようにします。通信相手の鍵を入れ替える中間者攻撃を見抜くための基盤です。
証明書が保証するのは、定められた手順で確認した名前・組織と公開鍵の結び付きです。そのサイトの商品、主張、運営者の誠実さまで審査する万能な信用印ではありません。
PKIに登場する主体
証明書を申請し、ドメインの管理権限を証明して、秘密鍵と更新を管理します。
登録局として、ドメインや組織の確認をCAに代わって行う場合があります。
認証局として、証明書方針と認証業務規程に従って発行・失効します。
ブラウザー、OS、アプリケーションなどがルート証明書ストアと方針を使って判断します。
証明書連鎖を上へたどる
- サーバー証明書を受け取る接続先ドメイン、公開鍵、期限、発行者、用途などを確認します。
- 中間CAの署名を検証するサーバーが送る中間証明書を使い、一段上の公開鍵で署名を確かめます。
- ルートCAへ到達する最上位の自己署名ルートが端末の信頼保存領域に信頼済みで登録されているか確認します。
- 接続方針を評価する名前一致、時刻、鍵用途、アルゴリズム、失効、CTなどを合わせて判断します。
ルートの秘密鍵は事故時の影響が極めて大きいため、オフライン保管や厳格な鍵生成式で扱い、日常発行は中間へ委ねます。中間を分ければ、用途制限と事故範囲の縮小ができます。
DV・OV・EVが確認する範囲
| 種類 | CAが主に確認すること | 読み取るときの注意 |
|---|---|---|
| DV | 申請者がドメインを制御できること | 法人の実在やサイト内容を保証しない |
| OV | ドメイン制御に加え組織情報 | ブラウザー表示でDVと見分けにくい場合がある |
| EV | 定められた詳細な組織確認 | 取引の安全や商品品質を保証しない |
無料・有料は暗号強度を決めません。同じ鍵アルゴリズムと適切な設定なら、無料DV証明書でも通信暗号化の役割を果たします。価格差にはサポート、組織確認、管理機能などが含まれます。
ルート保存領域が信頼の入口になる
CAが自分で「信頼できる」と名乗るだけではブラウザーに認められません。OS・ブラウザー製造元のルートプログラムが監査、安全性、発行方針、障害事案対応などを審査し、ルート証明書を信頼保存領域へ含めます。
同じサーバー証明書でも、古い端末や独自アプリケーションの信頼保存領域に必要なルートがなければエラーになります。反対に企業内端末へプライベートルートを導入すれば、社内CAの証明書を信頼できます。
誤発行と失効を抑える仕組み
CAA DNS記録は、そのドメインの証明書発行を許すCAを宣言します。CAは発行前に確認しますが、CAAだけで申請者認証を置き換えるものではありません。
Certificate Transparency（CT）は公開TLS証明書を追記専用ログへ記録し、ドメイン管理者やブラウザーが誤発行を監視しやすくします。秘密のプライベートホスト名を公開証明書へ入れる設計は避けます。
秘密鍵漏えい、誤発行、ドメイン制御喪失時は証明書を失効させます。ブラウザーはCRL・OCSP・配布済み拒否一覧などを使いますが、オフライン、応答遅延、プライバシー、可用性の長所と短所があるため、短い有効期間と自動更新も重要です。
警告を消すためだけに証明書を入れない
名前不一致、期限切れ、連鎖不足、端末時刻ずれ、古いアルゴリズム、信頼されていないプライベートCAなど、警告には原因があります。利用者へ「無視して進む」と案内する前に、サーバー証明書、中間連鎖、DNS名、時刻を修正します。
認証局は、確認した名前・組織と公開鍵を署名で結び、信頼保存領域からたどれる証明書連鎖を作ります。暗号化と相手鍵の確認を支えますが、サイト内容や取引の善良さは別に判断します。
公開TLS証明書の確認・発行要件：CA/Browser Forum「Baseline Requirements」