ブラウザに組み込まれた認証局リストとは何か — ルートストアとHTTPS信頼構造を理解する

ウェブサイトにアクセスすると、アドレスバーに鍵のアイコンが表示されます。ブラウザはサーバーから送られてきた証明書を確認し、接続先のドメインが正しいか、証明書が有効か、信頼できる認証局によって発行されたものかを判断します。

ここで一つの疑問が生まれます。

ブラウザはどの認証局を信頼すべきか、どのように知っているのでしょうか？

その基準となるのがルートストア（Root Store）、つまり信頼できるルート認証局のリストです。一般的に「ブラウザに認証局リストが組み込まれている」と表現されますが、実際の構造はもう少し複雑です。ブラウザが独自のリストを使用することもあれば、オペレーティングシステムのリストを使用することもあり、企業管理者が別途プライベート認証局を追加することも可能です。

この記事では、ブラウザとオペレーティングシステムに登録されている認証局リストとは何か、Chrome・Firefox・Safariがそれぞれどのように異なるのか、認証局がリストに含まれたり削除されたりすると何が起こるのかを詳しく見ていきます。

ブラウザが証明書チェーンをたどってルート認証局の信頼性を確認する構造

まず区別すべき3種類の証明書

HTTPS証明書を理解するには、サーバー証明書、中間証明書、ルート証明書を区別する必要があります。

分類	役割	一般的な場所
サーバー証明書	接続されたドメインと公開鍵を関連付ける	ウェブサーバーからブラウザに送信される
中間証明書	ルートCAに代わってサーバー証明書を発行する	ウェブサーバーからチェーンの一部として送信される
ルート証明書	証明書チェーンの最終的な信頼の基準	ブラウザまたはOSのルートストア

例えば、www.example.comのサーバー証明書が中間CAによって署名され、その中間CA証明書がルートCAにつながると仮定してみましょう。

신뢰된 루트 CA
    └── 중간 CA
          └── www.example.com 서버 인증서

ブラウザはサーバーから送られてきた証明書チェーンを検証し、自身が信頼するルートまでつながっているかを確認します。これを証明書パス検証または信頼のチェーン検証と呼びます。

重要な点は、ルート証明書リストには認証局の公開鍵と身元情報が含まれていることです。認証局の秘密鍵がブラウザに含まれているわけではありません。ルートCAの秘密鍵は認証局が別途保護し、ブラウザは公開鍵で署名の有効性を検証します。

ルートストアは単なる証明書ファイルの集まりではない

ルートストアは基本的に、信頼アンカーとして使用するルート証明書の集合です。しかし、実際の製品では証明書以外にも様々なポリシーが一緒に適用されます。

特定のルートCAの信頼の有無
TLSサーバー認証に使用できるか
証明書が適用されるDNS名や発行時点の制約
ブロックされたCAと証明書
Certificate Transparency要件
許可される鍵のサイズと署名アルゴリズム
サーバー証明書の最大有効期間
証明書失効情報

したがって、同じルート証明書を持っているからといって、すべてのブラウザが完全に同じ結果を出すわけではありません。証明書パスの構築方法、中間証明書の選択、失効確認、ローカルポリシー、およびブラウザごとの追加のセキュリティルールが異なる可能性があるためです。

ルートストアを次のように理解すると便利です。

ルートストアは「この認証局を無条件に信頼する」というリストではなく、証明書検証を開始できる信頼アンカーと、その信頼に適用するポリシーの集合である。

Chromeは現在、独自のルートストアを使用している

以前のChromeは、WindowsやmacOSのようなオペレーティングシステムの証明書ストアと検証機能に大きく依存していました。この方式では、同じChromeバージョンであっても、オペレーティングシステムによって証明書検証の結果が異なる可能性がありました。

現在、Chromeはサポートされている主要なプラットフォームでChromeルートストア（Chrome Root Store）とChrome証明書検証機能（Chrome Certificate Verifier）を使用しています。Googleが公開で運用するルートプログラムを基準に公開CAリストを管理し、Chromeが共通の方法で証明書パスを検証します。

Chromeルートストアの特徴は以下の通りです。

Chromeがデフォルトで信頼する公開ルートCAはGoogleが管理しています。
ルートストアはChromeバイナリに含まれています。
変更されたリストは、Component Updaterを通じてブラウザ全体のアップデートとは別に配布されることがあります。
一般的なルートストアのアップデートは、およそ四半期ごとに行われることがあります。
緊急のセキュリティ問題がある場合は、定期的な周期とは別に変更されることがあります。
ChromeはRFC 5280に基づく検証の他に、Certificate Transparencyや証明書の有効期間などの追加ポリシーを適用します。

Chromeルートプログラムは、CAが公開ルートリストに含まれるための最低要件を定めています。CA/Browser Forumのベースライン要件の遵守、CCADB情報の公開、定期監査、事故対応などが重要な審査要素です。

独自のルートストアを使用すると、企業のプライベートCAは無視されるのか？

そうではありません。

Chrome証明書検証機能は、公開ウェブ用のChromeルートストアとは別に、ユーザーまたは組織管理者がローカルで設定した信頼決定も考慮します。例えば、企業がWindowsグループポリシーやmacOS管理プロファイルで社内ルートCAを配布した場合、Chromeは内部サイトの証明書を検証する際にこれを使用できます。

ただし、公開ルートとローカルルートは同じ意味ではありません。

項目	公開ルートCA	ローカル・プライベートルートCA
主な用途	公開インターネットサイト	社内システム、開発環境、セキュリティプロキシ
包含主体	ブラウザ・OSのルートプログラム	ユーザーまたは組織管理者
適用範囲	そのルートストアを使用する多数のユーザー	証明書がインストールされた機器とアカウント
検証基準	公開ポリシー、監査、CCADB、業界要件	組織内部ポリシー
誤って信頼した場合の影響	世界的な証明書誤発行のリスク	管理範囲内のHTTPS傍受のリスク

Chromeの公式ドキュメントには、ローカルの信頼決定がTCPベースのTLS接続では信頼の追加と削除に考慮され、QUIC接続ではローカル決定のうち信頼の削除のみが考慮されるという詳細な違いも説明されています。したがって、プライベートPKIを使用する環境では、TCPとQUICの動作、ブラウザポリシー、実際の展開方法を一緒にテストする必要があります。

Chromeでリストを確認する方法

Chromeが実際に使用しているChromeルートストアの内容を確認するには、次の内部ページを使用できます。

chrome://system

ページでchromerootstore項目を展開すると、現在Chromeが認識しているルートストア情報を確認できます。

証明書管理は次のページからアクセスできます。

chrome://certificate-manager

Chromeのバージョンとオペレーティングシステムによって、画面構成と提供機能は異なる場合があります。公開ルートリスト、ローカルで追加された証明書、およびオペレーティングシステムが管理する証明書を同じものと解釈しないことが重要です。

FirefoxはMozillaルートストアを中心に動作する

Firefoxは長年にわたり、Mozillaが管理する独自のルート証明書リストを使用してきました。Mozillaルートストアに含まれるCAは、MozillaルートストアポリシーとCA証明書プログラムの要件に従う必要があります。

このため、同じコンピューターでChromeは正常なのにFirefoxでSECERRORUNKNOWN_ISSUERが発生する事例がありました。オペレーティングシステムには会社のプライベートCAが登録されているが、Firefoxがそれを使用しない環境が代表的です。

最近、FirefoxはWindows、macOS、Androidで、オペレーティングシステムに追加されたサードパーティのルート証明書を自動的に見つけて信頼できる機能をデフォルトで提供しています。Firefox 120から関連する動作が一般ユーザーにもデフォルトで有効化されました。

設定では次の項目で管理できます。

설정
  └── 개인정보 및 보안
        └── 인증서
              └── 설치한 제3자 루트 인증서를 Firefox가 자동으로 신뢰하도록 허용

企業環境では、security.enterprise_roots.enabled設定またはFirefox Enterprise Policyを使用できます。Linuxでは、ディストリビューションのPKI構造とp11-kit連携の有無を別途確認する必要があります。

Firefoxの動作をまとめると以下の通りです。

公開ウェブの基本的な信頼基準はMozillaルートストアです。
オペレーティングシステムや組織が追加したサードパーティCAも、設定とプラットフォームに応じて使用できます。
Firefoxの証明書マネージャーで別途CAをインポートすることもできます。
公開ルートストアと組織のプライベートCAは、互いに異なる信頼の出所です。

SafariはAppleオペレーティングシステムの信頼ストアを使用する

SafariはAppleプラットフォームのルートストアと証明書検証体系を使用します。AppleはiOS、iPadOS、macOS、tvOS、visionOS、watchOSで使用するルート証明書リストを管理し、公開しています。

Appleオペレーティングシステムは共有ルートストアを使用しており、Appleサポートドキュメントでオペレーティングシステムバージョンごとの信頼ルートとブロックされた証明書を確認できます。

macOSでは、キーチェーンアクセスまたはシステム設定を通じて証明書を表示できます。

응용 프로그램
  └── 유틸리티
        └── 키체인 접근
              └── 시스템 루트 / 시스템 / 로그인

3つのキーチェーンは意味が異なります。

システムルート: Appleがデフォルトで提供するルート証明書
システム: デバイス全体にインストールされた組織・管理者証明書
ログイン: 現在のユーザーにインストールされた証明書

組織はMDM構成プロファイルを通じてプライベートルートCAを配布できます。ユーザーが手動でインストールした証明書は、プラットフォームポリシーに応じて追加の信頼設定が必要となる場合があります。

iOS版Chromeも例外ではありません。Appleのプラットフォームポリシーのため、iOS版ChromeはChromeルートストアとChrome証明書検証機能を使用できず、Appleの証明書検証体系に依存します。したがって、名前はChromeですが、デスクトップ版Chromeとルートストアの動作が同じだと考えるべきではありません。

WindowsルートストアとEdgeはどのように異なるのか？

WindowsはMicrosoft Trusted Root Certificate Programを通じて、信頼ルートと信頼しない証明書リストを配布します。Windowsとアプリケーションは、証明書信頼リスト（Certificate Trust List）、つまりCTLを証明書の信頼判断に活用します。

Windowsにはおおよそ次のような証明書保存範囲があります。

ローカルコンピューター
現在のユーザー
グループポリシー
エンタープライズ
信頼されたルート証明機関
信頼されていない証明書

管理ツールは次のように分かれます。

certmgr.msc   # 現在のユーザー証明書
certlm.msc    # ローカルコンピューター証明書

WindowsはWindows Updateベースの自動メカニズムでTrusted CTLとUntrusted CTLを更新できます。Microsoftのドキュメントによると、自動更新を無効にすることもできますが、セキュリティ上推奨されません。

注意すべき点は、Windows証明書管理画面に表示されるすべての公開ルートが、必ずしもファイル形式で事前にインストールされているわけではないということです。CTLと自動ルート更新メカニズムを通じて、必要なときに信頼情報と証明書が供給されることがあります。

EdgeもChromiumベースですが、製品ポリシーやプラットフォーム統合の観点からChromeと完全に同一であると断定すべきではありません。特に企業環境では、Edgeポリシー、Windows証明書ストア、公開ルートストアとローカルCAの適用状況を実際の対象バージョンで確認する必要があります。

ブラウザごとに信頼結果が異なる理由

同じサイトなのに、あるブラウザでは正常で、別のブラウザでは警告が発生することがあります。

原因	説明
ルートストアの差異	あるプログラムにはルートCAがあり、別のプログラムにはない場合がある
中間証明書の欠落	サーバーが完全なチェーンを送信しないため、ブラウザごとの補完結果が異なる
パス構成の差異	クロス署名証明書が複数ある場合に選択されるパスが異なる
ローカルCA連携の差異	オペレーティングシステムに追加されたプライベートCAの読み取り方法が異なる
失効情報の差異	CRL、OCSP、ブラウザごとのブロックリストの適用方法が異なる
追加のセキュリティポリシー	CT、アルゴリズム、証明書の有効期間と名前の制約の適用が異なる
製品・OSバージョン	ルートストアと検証ロジックの更新タイミングが異なる

エラーが発生した際に、すぐにルート証明書をインストールするのは良い最初の対応ではありません。まず、サーバーが正しい証明書チェーンを提供しているかを確認する必要があります。

次の順序で調査する方が安全です。

接続したホスト名と証明書のSANが一致するか確認します。
サーバー証明書の有効期間を確認します。
サーバーが必要な中間証明書をすべて送信しているか確認します。
チェーンがどのルートCAに接続されているか確認します。
該当ルートがブラウザの公開ルートストアまたは承認されたローカルストアにあるか確認します。
セキュリティプロキシやウイルス対策ソフトがHTTPSを途中で再署名していないか確認します。
ブラウザ・オペレーティングシステム・ルートストアの更新状況を確認します。

会社のPCにプライベートルートCAが追加される理由

企業環境では、公開CAだけでは解決が難しい場合があります。

社内ドメインと内部サービスへの証明書発行
開発・テスト環境でのTLS適用
機器認証と相互TLS
セキュリティプロキシによるHTTPS検査
DLP、マルウェア分析、アクセス制御

特にHTTPS検査機器は、クライアントと外部サイトの間でTLS接続を2つに分割します。

브라우저 ← TLS 1 → 보안 프록시 ← TLS 2 → 외부 웹사이트

セキュリティプロキシは外部サイトの証明書を確認した後、接続ドメインに対する新しい証明書をリアルタイムで作成し、ブラウザに提供します。ブラウザがこの証明書を警告なしに受け入れるためには、セキュリティプロキシのルートCAがクライアントの信頼ストアにインストールされている必要があります。

これは運用上必要な制御となる場合がありますが、非常に強力な権限です。該当ルートCAの秘密鍵を持つシステムは、管理対象機器で様々なHTTPSサイトの証明書を作成できるためです。

プライベートルートCAを配布する際には、少なくとも次の制御が必要です。

ルートCA秘密鍵をHSMやオフライン環境で保護
実際の発行は制限された中間CAが実行
証明書発行と管理者作業の監査
対象機器と使用目的を最小化
退職者・紛失機器・廃棄機器の証明書とポリシーの回収
有効期限と交換計画の策定
TLS検査除外対象と個人情報処理基準の定義
障害発生時にルートストアとプロキシポリシーを一緒に点検

ルートCAがリストに含まれる過程

公開CAが証明書をブラウザ会社に1つ送ったからといって、すぐに信頼されるわけではありません。

一般的に、次のような手順と継続的な義務が必要です。

ルートプログラムの包含要件を満たします。
証明書ポリシー（CP）と証明書運用規程（CPS）を公開します。
WebTrustまたはETSI系列の独立監査を受けます。
ルートおよび中間CA情報をCCADBに公開します。
公開レビューと質問に対応します。
CA/Browser Forumベースライン要件を遵守します。
証明書の誤発行とセキュリティインシデントを報告し、対応します。
包含後も定期監査とポリシー遵守を継続します。

信頼は永続的な権利ではありません。ポリシー違反、証明書の誤発行、監査失敗、秘密鍵の侵害、または不十分な事故対応が発生した場合、ルートが制限されたり削除されたりする可能性があります。

ルートCAが削除されても、すでに発行されたすべての証明書が同時に同じように失敗するわけではありません。ブラウザのバージョン、ルートストアの更新状況、クロス署名パス、証明書の発行時点の制約、およびローカルポリシーによって結果が異なる場合があります。

ルートストアのアップデートがセキュリティアップデートである理由

ルートストアの変更は、単なる証明書リストの整理ではありません。

新しいCAを追加すると、そのCAが発行した証明書がデフォルトで信頼されるようになります。逆に、問題のあるCAを削除すると、攻撃者が誤って発行された証明書を使用しても、ブラウザが信頼しないようにすることができます。

アップデートが停止したブラウザやオペレーティングシステムでは、次の問題が発生する可能性があります。

新しいルートCAを使用する正常なサイトへの接続失敗
削除されたCAを信頼し続ける
新しい証明書の制約とブロックポリシーが適用されない
古いアルゴリズムと検証ロジックの使用
プライベートPKIの変更との不一致

閉鎖ネットワークでは、ブラウザの自動アップデートとWindows CTLアップデートがブロックされやすいです。この場合、ブラウザの実行ファイルだけを配布するだけで十分なのか、ルートストアコンポーネントと信頼しない証明書リストまで更新されるのかを別途確認する必要があります。

オペレーターが確認すべき主要な質問

ルートストアの問題を扱う際には、「証明書がインストールされているか？」という質問だけでは不十分です。

確認すべき質問	理由
このブラウザの公開信頼リストは誰が管理しているのか？	Chrome、Mozilla、Apple、Microsoftのプログラムが異なる
現在のプラットフォームで、独自のストアとOSストアのどちらを使用しているのか？	同じブラウザでもプラットフォームごとに違いがある
組織が追加したローカルCAはどの範囲にインストールされているのか？	ユーザー、機器、グループポリシーの適用範囲が異なる
該当CAはTLSサーバー認証の目的で信頼されているか？	証明書があっても、用途制限により失敗する可能性がある
ルートストアとブロックリストはどのように更新されるのか？	閉鎖ネットワークとアップデートがブロックされた環境で重要
サーバーは中間証明書を正しく送信しているか？	最も一般的なチェーンエラーの一つ
HTTPS検査機器が証明書を再署名しているか？	ブラウザが見る発行者が元のCAと異なる場合がある
ルートCA秘密鍵と発行システムは安全か？	プライベートCAの侵害は組織全体のTLS信頼に影響

## 結論：ブラウザの鍵は信頼リストとポリシーの結果である

ブラウザは世界中のすべての証明書を事前に知っているわけではありません。信頼できると判断したルートCAを起点として、サーバー証明書まで続くチェーンを検証します。

Chromeは独自のChromeルートストアと証明書検証機能を使用し、組織が配布したローカルの信頼も考慮します。FirefoxはMozillaルートストアを中心に動作しますが、オペレーティングシステムに追加されたサードパーティのルートも活用できます。SafariとiOS版ChromeはAppleプラットフォームの信頼ストアと検証体系に依存します。WindowsはMicrosoftルート証明書プログラムとCTL更新メカニズムでシステムの信頼情報を管理します。

結局、HTTPSの鍵は暗号化アルゴリズム一つだけで作られるものではありません。

どの認証局を信頼するかを定めるルートプログラム、機器に展開されたルートストア、サーバーが提供した証明書チェーン、ブラウザの検証ポリシー、そして組織のローカルな信頼決定が共に作り出した結果である。

証明書エラーを解決する際に、むやみにルート証明書をインストールするのではなく、どのルートストアが使用されているのか、なぜチェーンが信頼されないのかをまず確認する必要があります。特にプライベートCAとHTTPS検査環境では、利便性のために追加した信頼がどの範囲まで権限を持つのかを一緒に管理する必要があります。