デジタル証明書完全ガイド：ルート証明書・中間証明書・サーバー証明書の仕組みを体系的に解説

はじめに

ウェブブラウザのアドレスバーに表示される「鍵マーク」や「https://」。これらはデジタル証明書によって支えられています。しかし「ルート証明書」「中間証明書」「サーバー証明書」「CA証明書」など、似た名前が多すぎて混乱してしまうのは当然です。

本記事では、デジタル証明書の全体像をゼロから体系的に解説します。「なぜ必要なのか」という根本から始め、各証明書の種類・役割・使われ方まで、初心者にも分かるように丁寧に説明します。

この記事で分かること

• デジタル証明書が解決する問題と基本的な仕組み
• PKI（公開鍵基盤）の全体像
• ルート証明書・中間証明書・サーバー証明書などの種類と役割の違い
• 「信頼チェーン」がどのように機能するか
• ブラウザがHTTPS接続時に何を検証しているか
• DV・OV・EV証明書の違い
• PEM・DER・PFX などのファイル形式
• 証明書の失効（CRL/OCSP）の仕組み

1. そもそもなぜデジタル証明書が必要なのか

1.1 インターネット上の「なりすまし」問題

インターネットで情報をやり取りするとき、「相手が本当に本物かどうか」を確認する手段がなければ、悪意のある第三者が本物のサーバーに成りすまして通信を盗聴・改ざんできてしまいます。

【なりすまし攻撃の例（証明書なし）】

ユーザー ──→ 「bank.example.com」に接続しているつもり
                      ↓
              実は偽サイト（攻撃者のサーバー）
              ユーザーのID・パスワードを盗む

デジタル証明書は、この問題を解決するための「信頼できる第三者機関が発行した身分証明書」です。

1.2 デジタル証明書が解決する3つの問題

2. 公開鍵暗号の基礎

デジタル証明書を理解するには、「公開鍵暗号」の基礎を押さえる必要があります。

2.1 公開鍵と秘密鍵のペア

公開鍵暗号では、数学的に対になった2つの鍵（公開鍵と秘密鍵）を使います。

【公開鍵と秘密鍵の特性】

公開鍵で暗号化 → 秘密鍵でのみ復号できる（暗号化通信）
秘密鍵で署名  → 公開鍵で署名を検証できる（デジタル署名）

• 公開鍵：誰にでも公開してよい鍵
• 秘密鍵：絶対に公開しない自分だけの鍵

この2つの鍵は必ずペアで生成され、片方で処理したものはもう片方でしか処理できません。

2.2 デジタル署名の仕組み

デジタル証明書の根幹となるのが「デジタル署名」です。

2.3 デジタル証明書とは何か

デジタル証明書とは、公開鍵とその持ち主の情報を紐付け、信頼できる第三者機関（認証局）がデジタル署名した電子的な文書です。

証明書には主に以下の情報が含まれます：

【X.509証明書の主な内容】
- バージョン番号
- シリアル番号（認証局内で一意）
- 署名アルゴリズム（SHA-256 with RSA など）
- 発行者（Issuer）：この証明書を発行した認証局の名前
- 有効期間（開始日・終了日）
- 主体者（Subject）：証明書の持ち主の情報
  - CN (Common Name)：ドメイン名や組織名
  - O (Organization)：組織名
  - C (Country)：国コード
- 主体者の公開鍵
- 拡張領域（用途、SANなど）
- 発行者のデジタル署名

3. PKI（公開鍵基盤）の全体像

3.1 PKIとは

**PKI（Public Key Infrastructure：公開鍵基盤）**とは、デジタル証明書を発行・管理・失効させるための仕組み全体を指します。

3.2 PKIの主要な構成要素

4. 証明書の種類と役割

ここが一番混乱しやすいポイントです。証明書の種類を役割の観点から整理します。

4.1 全体の関係性

4.2 CA証明書（認証局証明書）

CA証明書は、他の証明書を発行する権限を持つ認証局（CA: Certificate Authority）自身の証明書です。

「ルート証明書」も「中間証明書」も、どちらもCA証明書の一種です。CA証明書かどうかは、証明書の中の Basic Constraints: CA:TRUE という拡張フィールドで識別できます。

1
2
3

# 証明書がCA証明書かどうか確認するコマンド
openssl x509 -in certificate.pem -text -noout | grep -A1 "Basic Constraints"
# CA:TRUE なら認証局証明書、CA:FALSE ならエンドエンティティ証明書

4.3 ルート証明書（Root CA Certificate）

ルート証明書は、**信頼チェーンの最上位に位置する「究極の信頼の起点」**です。

特徴：

• 自己署名（Self-Signed）：自分自身の秘密鍵で署名している（発行者と主体者が同じ）
• OSやブラウザの「トラストストア」にあらかじめ組み込まれている
• 有効期間が非常に長い（20〜30年）
• 秘密鍵は厳重にオフラインで保管（HSM など）
• 日常的な証明書発行には使わない（リスク管理のため）

代表的なルート認証局：

• DigiCert, GlobalSign, Sectigo（旧Comodo）, Let’s Encrypt（ISRG Root X1）

【ルート証明書の特徴】
Issuer:  CN=DigiCert Global Root CA（発行者）
Subject: CN=DigiCert Global Root CA（主体者）← 同じ！
CA:TRUE
自己署名証明書

4.4 中間証明書（Intermediate CA Certificate）

中間証明書は、ルート証明書とエンドエンティティ証明書の間を橋渡しする証明書です。

なぜ中間証明書が存在するのか？

ルート証明書の秘密鍵は極めて重要なため、日常的な証明書発行に使うとリスクが高まります。そこで「中間CA」に証明書発行の役割を委任します。万が一中間CAが侵害されても、ルートCAはその中間CAを失効させるだけで済みます。

特徴：

• ルート証明書に署名されている（発行者がルートCA）
• CA:TRUE で、さらに証明書を発行できる
• 有効期間は中程度（5〜10年）
• 実際の証明書発行作業はこの中間CAが行う
• 複数の中間CAが連なる場合もある（中間CAチェーン）

4.5 サーバー証明書（TLS/SSL証明書）

サーバー証明書は、Webサーバーに設置してHTTPS通信を実現するための証明書です。

特徴：

• 中間CAによって発行される
• CA:FALSE（他の証明書を発行できない）
• CN または SAN（Subject Alternative Name） にドメイン名が記載される
• 有効期間は最大398日（2020年以降の業界標準）
• ブラウザの鍵マークとHTTPS通信を実現する

1
2
3
4
5

# サーバー証明書の内容を確認
openssl s_client -connect example.com:443 -showcerts 2>/dev/null | openssl x509 -text -noout

# SANの確認
openssl x509 -in server.pem -text -noout | grep -A1 "Subject Alternative Name"

ワイルドカード証明書とマルチドメイン証明書：

4.6 クライアント証明書

クライアント証明書は、サーバーがクライアント（ユーザー/デバイス）の身元を確認するために使われます。

【サーバー証明書 vs クライアント証明書】
サーバー証明書：「このサーバーは本物ですか？」をクライアントが確認
クライアント証明書：「このクライアントは本物ですか？」をサーバーが確認

用途：

• VPN接続の認証（ユーザー認証の強化）
• 社内システムへのアクセス制御
• API接続のクライアント認証（mTLS）
• スマートカード/ICカードによる認証
• Microsoft Entra ID のデバイス証明書

4.7 コード署名証明書

コード署名証明書は、ソフトウェアやスクリプトに署名して「このコードは改ざんされていない」ことを証明します。

【コード署名の流れ】
開発者 → 秘密鍵でコードに署名 → 署名付きコードを配布
ユーザー → 開発者の公開鍵（証明書）で署名を検証 → 改ざんなしを確認

用途：

• Windowsの実行ファイル（.exe, .msi）
• PowerShellスクリプト
• macOS/iOSアプリ（Apple Developer証明書）
• Androidアプリ

4.8 メール証明書（S/MIME証明書）

S/MIME（Secure/Multipurpose Internet Mail Extensions）証明書は、メールの暗号化とデジタル署名に使います。

5. 信頼チェーン（Chain of Trust）

5.1 信頼チェーンとは

信頼チェーンとは、ルート証明書を起点として、中間証明書を経由してエンドエンティティ証明書まで繋がる「信頼の連鎖」です。

「信頼の伝達」の仕組み：

1. OSはルート証明書を「無条件に信頼する」としてインストール済み
2. ルートCAが中間CAの証明書に署名 → ルートを信頼するなら中間CAも信頼できる
3. 中間CAがサーバー証明書に署名 → 中間CAを信頼するならサーバー証明書も信頼できる

5.2 証明書チェーンの確認

1
2
3
4
5
6
7
8
9

# サーバーが送ってくる証明書チェーンを確認
openssl s_client -connect example.com:443 -showcerts

# 出力例：
# Certificate chain
#  0 s:CN=example.com               ← サーバー証明書
#    i:CN=Let's Encrypt R11          ← 発行者（中間CA）
#  1 s:CN=Let's Encrypt R11          ← 中間証明書
#    i:CN=ISRG Root X1               ← 発行者（ルートCA）

5.3 証明書チェーンが正しく設定されないとどうなるか

サーバー管理者が中間証明書を設定し忘れると、ブラウザが証明書チェーンを辿れず「信頼できない証明書」エラーが発生します。

【よくあるエラーの原因】
ブラウザ → サーバー証明書受信 → 発行者の証明書（中間CA）を探す
                                    ↓
                          中間証明書がサーバーから送られない
                                    ↓
                          ルートまで辿れずエラー！

6. 証明書の検証フロー

6.1 ブラウザがHTTPS接続時に行う検証

ブラウザが https://example.com に接続するとき、以下の検証を行います。

6.2 TLSハンドシェイクの流れ

証明書検証はTLSハンドシェイクの一部として行われます。

7. 証明書の検証レベル（DV・OV・EV）

サーバー証明書は、発行前に行われる身元確認の厳格さによって3種類に分類されます。

7.1 DV・OV・EV の比較

7.2 各種類の特徴

DV証明書（ドメイン認証）

• Let’s Encryptが無料で提供（3ヶ月更新）
• HTTPファイルの設置やDNSレコードで所有権を確認
• 「このドメインの所有者が証明書を取得した」ことだけを保証
• 組織名は証明書に含まれない

OV証明書（組織認証）

• 実在する組織であることを確認（登記情報・電話確認など）
• 証明書の O（Organization） フィールドに組織名が入る
• 企業のウェブサイトに適切

EV証明書（拡張認証）

• CA/Browser Forumが定めた厳格な審査基準
• 法人登記、所在地、電話番号などを多角的に確認
• かつては緑色のアドレスバーで表示されたが、現在多くのブラウザで廃止
• 証明書内に組織名が明記される

8. 証明書のファイル形式

証明書や鍵は様々なファイル形式で存在します。混乱しやすいポイントです。

8.1 主なファイル形式の比較

8.2 PEM形式

最も一般的な形式です。テキストエディタで開くとBase64エンコードされた内容が見えます。

-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
...（省略）
-----END CERTIFICATE-----

1つのPEMファイルに複数の証明書を連結することで、証明書チェーンを表現できます。

8.3 形式変換コマンド

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# PEM → DER 変換
openssl x509 -in cert.pem -outform DER -out cert.der

# DER → PEM 変換
openssl x509 -in cert.der -inform DER -out cert.pem

# PEM → PFX 変換（秘密鍵と証明書を統合）
openssl pkcs12 -export -out cert.pfx -inkey private.key -in cert.pem -certfile chain.pem

# PFX → PEM 変換（証明書と秘密鍵を分離）
openssl pkcs12 -in cert.pfx -clcerts -nokeys -out cert.pem
openssl pkcs12 -in cert.pfx -nocerts -nodes -out private.key

# 証明書の内容を確認（PEM形式）
openssl x509 -in cert.pem -text -noout

# 証明書の有効期限を確認
openssl x509 -in cert.pem -noout -enddate

9. 証明書の失効（CRL と OCSP）

9.1 なぜ失効が必要か

証明書の有効期限内でも、秘密鍵の漏洩や誤発行などがあった場合、証明書を無効化（失効） する必要があります。

9.2 CRL（証明書失効リスト）

CRL（Certificate Revocation List） は、失効した証明書のシリアル番号を列挙したリストです。

【CRLの仕組み】
1. CAが失効した証明書のリストを定期的に発行
2. クライアントがリストをダウンロード
3. 接続先の証明書がリストに含まれないか確認

CRLの課題：

• リストが大きくなりすぎる（特に大規模CA）
• 更新頻度が低いとリアルタイムの失効情報を反映できない
• 毎回ダウンロードする帯域・時間のコスト

9.3 OCSP（オンライン証明書状態プロトコル）

OCSP（Online Certificate Status Protocol） は、特定の証明書の有効性をリアルタイムで問い合わせるプロトコルです。

9.4 OCSP Stapling

OCSP Stapling は、サーバー自身がOCSPレスポンスを事前に取得してクライアントに提示する仕組みです。

【通常のOCSP】
クライアント → OCSPレスポンダーに問い合わせ（遅延が発生）

【OCSP Stapling】
サーバー → 事前にOCSPレスポンスを取得・キャッシュ
クライアント → TLSハンドシェイク中にOCSPレスポンスも受け取る（高速）

10. よくある混乱ポイント Q&A

Q1. 「CA証明書」と「ルート証明書」は同じもの？

A. 違います。CA証明書とは「他の証明書を発行できる認証局の証明書」の総称で、ルート証明書と中間証明書の両方が含まれます。ルート証明書は特に「自己署名かつ信頼の起点となるCA証明書」のことです。

Q2. 「SSL証明書」と「TLS証明書」と「サーバー証明書」は違う？

A. 実質的に同じものを指しています。SSLは古い規格名で、現在はTLSが使われていますが、慣習的に「SSL証明書」と呼ばれることが多いです。「サーバー証明書」はサーバーに設置するという用途から来た呼び方です。

Q3. 中間証明書は何枚あってもいい？

A. 技術的には複数の中間CAを連ねることができます（ルート → 中間CA1 → 中間CA2 → サーバー証明書）。ただしチェーンが長くなるほどTLSハンドシェイクが遅くなるため、実用的には2段階（ルート → 中間 → サーバー）が多いです。

Q4. 「自己署名証明書」とは何？

A. 認証局ではなく自分自身の秘密鍵で署名した証明書です。テスト環境やプライベートネットワークで使われますが、ブラウザが「信頼できない証明書」として警告を表示します。ルート証明書も自己署名ですが、OSのトラストストアに登録されているため信頼されます。

Q5. 証明書の更新と再発行の違いは？

A. 「更新」は有効期限が切れる前に新しい証明書を取得することです。「再発行」は秘密鍵の漏洩などで証明書を失効させて新たに発行することを指します。Let’s Encryptは3ヶ月毎の更新が必要なため、自動更新（certbot –renew など）の設定が重要です。

Q6. .crt と .pem と .cer の違いは？

A. 実はエンコード形式（PEM/DER）とファイル拡張子は一致しないことが多く、混乱の原因です。.pem, .crt, .cer はすべてPEM形式（テキスト）でも DER形式（バイナリ）でも存在します。openssl x509 -in ファイル -text で中身を確認するのが確実です。

Q7. 「トラストストア」とは？

A. OSやブラウザが信頼するルート証明書の一覧です。Windowsは「証明書マネージャー（certmgr）」、macOSは「キーチェーンアクセス」、Linuxは /etc/ssl/certs/ などに格納されています。ここに登録されているルート証明書から繋がる証明書チェーンのみが信頼されます。

11. まとめ

デジタル証明書の全体像を整理すると以下のようになります。

証明書の種類まとめ

重要なポイントの整理

1. 信頼チェーン：ルート→中間→エンドエンティティの署名の連鎖で信頼が伝達される
2. 中間証明書の役割：ルートCAのリスクを分散させるバッファ層
3. DV/OV/EV：発行前の身元確認の厳格さの違い（技術的な暗号強度ではない）
4. ファイル形式：PEM（テキスト）、DER（バイナリ）、PFX（証明書+秘密鍵統合）
5. 失効確認：CRL（リスト方式）とOCSP（リアルタイム問い合わせ）

デジタル証明書は現代のインターネットセキュリティの根幹を支える技術です。各証明書の役割を理解することで、TLS設定のトラブルシューティングや証明書管理がより的確にできるようになります。