ルート認証局（Root CA）
概要
ルート認証局（Root CA） は、PKI（公開鍵基盤）における信頼の起点となる最上位の認証局です。RFC 5280 では「Trust Anchor」として定義されており、自分自身の公開鍵で署名した自己署名証明書（Self-Signed Certificate）を発行します。ブラウザーや OS はあらかじめ信頼できるルート認証局の証明書をトラストストアに組み込んでおり、TLS 接続時の証明書チェーン検証はこのルート証明書に到達することで完了します。
ルート認証局は通常、サーバー証明書を直接発行しません。日常的な証明書発行は中間認証局（Intermediate CA）に委ね、ルート CA の秘密鍵はオフラインの HSM（Hardware Security Module）に厳重に保管します。この階層構造により、仮に中間認証局が侵害されても、その中間証明書を失効させるだけでルート CA の信頼性は維持されます。
仕組み
ルート CA は自己署名証明書とトラストストアを基盤とし、中間 CA への階層委任で PKI 全体の信頼を構築しています。
自己署名証明書と信頼の起点
通常の SSL/TLS 証明書は、上位の認証局が秘密鍵で署名することで信頼を付与します。しかしルート認証局には自身より上位の認証局が存在しないため、自分自身の秘密鍵で自分の証明書に署名します。これが自己署名証明書です。
自己署名証明書は暗号学的には誰でも作成できます。開発環境で使う自己署名証明書と、ルート CA の自己署名証明書の違いは「ブラウザーや OS のトラストストアに組み込まれているかどうか」だけです。トラストストアに登録された自己署名証明書だけがルート証明書として機能し、証明書チェーン検証の終着点になります。
RFC 5280 の Section 6 では、証明書パス検証（Certification Path Validation）アルゴリズムの入力として Trust Anchor の主体者名（Subject）と公開鍵を要求しています。検証アルゴリズムはチェーンを末端から順にたどり、最終的にこの Trust Anchor に到達できれば検証成功と判定します。
トラストストア
ルート証明書は各プラットフォームのトラストストアに格納されています。
| プラットフォーム | トラストストアの場所 | 管理主体 |
|---|---|---|
| Windows | 「信頼されたルート証明機関」ストア | Microsoft |
| macOS / iOS | キーチェーン（System Roots） | Apple |
| Android | /system/etc/security/cacerts/ | Google / 端末メーカー |
| Firefox | NSS ビルトインストア | Mozilla |
| Linux (Debian/Ubuntu) | /etc/ssl/certs/ (ca-certificates) | ディストリビューション |
Firefox は OS のトラストストアを使わず独自のストアを持つ点が特徴的です。そのため、OS にルート証明書を追加しても Firefox には反映されません。企業環境でプライベート CA を運用する場合、Firefox への証明書配布には別途ポリシー設定が必要です。
Mozilla の CCADB（Common CA Database）には、TLS 用途で信頼されているルート証明書が約 144 件登録されています（2025 年時点）。Apple や Microsoft も独自のルートプログラムを運営していますが、CCADB を共通のデータベースとして利用しています。
ルート CA の秘密鍵管理
ルート CA の秘密鍵は PKI 全体の信頼基盤であるため、鍵の生成と管理には厳格な手順が求められます。
秘密鍵の生成は「キーセレモニー（Key Ceremony）」と呼ばれる正式な手続きで実施されます。ネットワークから完全に隔離されたエアギャップ環境で、FIPS 140-2 Level 3 以上の認定を受けた HSM 内で鍵を生成します。生成された秘密鍵は HSM の外に平文で出ることはありません。
キーセレモニーには複数の鍵管理者（Key Custodian）が立ち会い、鍵の有効化にはクォーラム（例: 5 名中 3 名の承認）が必要です。手順はすべてスクリプト化・文書化され、ビデオ録画と独立した監査人による記録が行われます。CA/Browser Forum の Baseline Requirements と各ブラウザーベンダーのルートプログラムが、この水準のセキュリティを要求しています。
ルート CA と中間 CA の階層構造
ルート CA が直接サーバー証明書を発行しない理由は、秘密鍵の保護とリスクの分離にあります。
[Root CA] ← オフライン、HSM に保管
└── 署名
[中間 CA (Intermediate CA)] ← オンライン、日常的に証明書を発行
└── 署名
[サーバー証明書] ← 各ウェブサーバーに配置ルート CA の秘密鍵をオフラインに保つことで、ネットワーク経由の攻撃から保護します。中間 CA が侵害された場合は中間証明書を失効させれば済みますが、ルート CA が侵害された場合はトラストストアからルート証明書を削除するしかなく、その CA が発行したすべての証明書が無効になります。
ルート証明書のライフサイクル
ルート証明書の有効期間はサーバー証明書よりはるかに長く、一般的に 20〜30 年 です。Let’s Encrypt の ISRG Root X1 は 2015 年発行で 2035 年まで有効です。
ただし、ブラウザーベンダーはルート証明書の長寿命化に制限を設け始めています。Mozilla は 2025 年にルート CA のライフサイクルポリシーを更新し、鍵の使用開始から 15 年 を超えたルート証明書について TLS 用途の信頼を段階的に削除する方針を示しました。この方針により、古い暗号アルゴリズムや鍵長のルート証明書が長期間信頼され続けるリスクを低減します。
CA/Browser Forum の Baseline Requirements では、ルート CA の RSA 鍵長は 2,048 ビット以上、ハッシュアルゴリズムは SHA-256 以上が求められます。ECDSA の場合は NIST P-256、P-384、P-521 が認められています。
Let’s Encrypt のルート CA 構成
Let’s Encrypt は ISRG（Internet Security Research Group）が運営する認証局で、現在の階層構造は次の通りです。
ISRG Root X1 (RSA, 2035年まで有効)
├── Let's Encrypt R10 (RSA 中間 CA)
├── Let's Encrypt R11 (RSA 中間 CA)
└── ...
ISRG Root X2 (ECDSA, 2035年まで有効)
├── Let's Encrypt E5 (ECDSA 中間 CA)
├── Let's Encrypt E6 (ECDSA 中間 CA)
└── ...RSA 証明書はデフォルトで ISRG Root X1 を終端とするチェーンで提供されます。ECDSA 証明書は ISRG Root X2 を終端とする短いチェーンも選択できますが、ISRG Root X2 は ISRG Root X1 よりトラストストアへの組み込みが新しいため、2022 年以前に更新が止まった古いクライアントでは信頼されない場合があります。
2025 年には次世代の「Generation Y」ルート証明書（ISRG Root YE、ISRG Root YR）のキーセレモニーが実施されました。これらはまだ各ブラウザーのトラストストアに組み込まれていませんが、将来的に現行のルート証明書からの移行先となります。
確認方法
openssl でサーバー証明書のチェーンを表示し、ルート CA を確認するには次のコマンドを使います。
# 証明書チェーンを表示してルート CA の Issuer を確認
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E "s:|i:" 0 s:CN = example.com
i:C = US, O = Let's Encrypt, CN = R10
1 s:C = US, O = Let's Encrypt, CN = R10
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1ルート証明書の詳細を確認するには次のコマンドを使います。
# ルート証明書の詳細を確認（Subject、有効期限、鍵アルゴリズム）
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -datesissuer=C = US, O = Let's Encrypt, CN = R10
notBefore=Jan 13 00:00:00 2026 GMT
notAfter=Apr 13 23:59:59 2026 GMTi: 行（Issuer）が s: 行（Subject）と同一の証明書が自己署名証明書、つまりルート証明書です。ただし、TLS ハンドシェイクでサーバーがルート証明書を送信するかどうかはサーバーの設定次第です。RFC 5246（TLS 1.2）では「ルート CA の自己署名証明書は省略してもよい（MAY）」と定められています。
OS にインストールされているルート証明書を一覧するには、プラットフォームごとに異なるコマンドを使います。
# macOS: キーチェーンのルート証明書を一覧
security find-certificate -a -p /System/Library/Keychains/SystemRootCertificates.keychain | grep -c "BEGIN CERTIFICATE"# Linux (Debian/Ubuntu): ca-certificates のルート証明書を一覧
ls /etc/ssl/certs/ | wc -l外部の視点からも確認したい場合は、Labee Dev Toolbox の SSL Cert API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/ssl-cert?hostname=example.com"{
"success": true,
"data": {
"hostname": "example.com",
"port": 443,
"reachable": true,
"status": 200
},
"error": null,
"meta": { "responseTime": 123 }
}data.reachable が true であれば、外部の環境から HTTPS 接続が成立しています。false の場合は、ルート証明書の信頼問題を含む何らかの TLS エラーが発生している可能性があります。レスポンスの error フィールドに原因の手がかりが含まれます。
よくある問題
ルート証明書の期限切れ、プライベート CA の信頼設定、ブラウザーベンダーによる Distrust がルート CA に関する代表的なトラブルです。
ルート証明書の期限切れによる大規模障害
ルート証明書の有効期限は 20〜30 年と長いため、更新が見過ごされることがあります。2021 年 9 月 30 日には Let’s Encrypt が以前使用していたクロス署名元の DST Root CA X3 が失効し、OpenSSL 1.0.2 を使う古い Linux システム（CentOS 7 など）で HTTPS 接続が一斉に失敗する障害が発生しました。
この問題はサーバー証明書そのものの期限切れではなく、クライアント側の OpenSSL が失効したルート証明書をチェーン検証に使い続けたことが原因です。OpenSSL 1.1.0 以降では代替チェーンを自動的に探索するため影響を受けませんでした。
プライベート CA のルート証明書が信頼されない
企業内でプライベート CA を構築した場合、そのルート証明書は公的なトラストストアに含まれていません。クライアント端末に手動でルート証明書をインストールする必要があります。
Active Directory 環境ではグループポリシーで配布できますが、Firefox は OS のトラストストアを参照しないため、security.enterprise_roots.enabled を true に設定するか、Firefox のポリシーテンプレートで別途配布する必要があります。macOS では MDM プロファイルで配布し、モバイルデバイスではプロファイルインストール後にユーザーが明示的に信頼を有効化する操作が必要です。
ルート CA の失効（Distrust）
ブラウザーベンダーがルート認証局のセキュリティ基準違反や不正発行を発見した場合、そのルート証明書をトラストストアから削除（Distrust）します。
過去の事例として、Symantec グループの CA は 2017〜2018 年にかけて Chrome と Firefox から段階的に Distrust されました。不正な証明書発行と監査上の問題が原因です。影響を受けたサーバー管理者は、DigiCert など別の CA から証明書を再取得する必要がありました。2022 年には TrustCor も Mozilla と Microsoft から Distrust されています。
ルート CA の Distrust は証明書チェーン全体に波及するため、自サイトの証明書が信頼されなくなります。CAA レコードで認証局を指定している場合でも、指定先の CA が Distrust されれば同じ影響を受けます。
ルート証明書の更新とトラストストアの同期
新しいルート証明書がトラストストアに追加されるには、各プラットフォームのアップデートが必要です。OS やブラウザーの更新を停止した環境では、新しいルート CA から発行された証明書が信頼されません。
Android は OS アップデートの提供が端末メーカーに依存するため、古い端末ではトラストストアが更新されないことがあります。Let’s Encrypt が ISRG Root X2 から発行する ECDSA 証明書は、2022 年頃以前のトラストストアを持つ端末では信頼されない可能性があります。