【情報セキュリティマネジメント】PKIとデジタル証明書、分かれ目は「どこまで確認したか」｜証明書チェーン・ルート証明書・CRL・証明書失効

デジタル署名を検証するには、署名者に対応する検証鍵が必要です。

しかし、手元にある検証鍵が、本当に目的の相手のものか確認できなければ、攻撃者の公開鍵へ差し替えられていても気付けない可能性があります。

この問題に対応する仕組みが、PKIとデジタル証明書です。

PKIでは、次を組み合わせて、公開鍵を信頼して利用できるようにします。

• 主体の識別情報と公開鍵を結び付けるデジタル証明書
• 証明書を発行・署名する認証局
• 信頼の基点となるトラストアンカー
• ルート証明書・中間CA証明書・利用者又はサーバ証明書の連鎖
• 有効期間と失効状態の確認
• 認証局と証明書利用者の鍵管理・運用

この記事では、デジタル署名の記事で残した「その検証鍵は本当に本人のものか」という問いに答えます。

読み終えるころには、証明書を示されたときに署名の連鎖・有効期間・対象名・鍵用途・失効状態のどれをまだ確認していないかを自分で切り分けられるようになります。

先に結論：証明書があるだけでは安全と判断しない

重要なのは、次の考え方です。

証明書の署名が正しいこと、有効期間内であること、失効していないこと、利用目的に合っていることは、それぞれ別に確認します。

1．PKIとは

PKIはPublic Key Infrastructureの略で、日本語では公開鍵基盤といいます。

公開鍵暗号方式やデジタル署名を組織・社会で利用するには、公開鍵そのものだけでなく、その鍵を誰のものとして信頼するかを管理する必要があります。

PKIには、次のような技術・組織・運用が含まれます。

• デジタル証明書の申請・発行
• 申請者・組織の確認
• 認証局による証明書への署名
• 証明書チェーンの構築・検証
• トラストアンカーの管理
• 証明書の有効期間管理
• 証明書の失効・CRLの発行
• 認証局・利用者の秘密鍵管理
• 証明書ポリシー・運用規程
• インシデント時の対応

PKIは一つの暗号アルゴリズムではありません。

公開鍵と主体の結び付きを、技術・組織・運用によって信頼できるようにする基盤です。

なお、「認証局」「証明書チェーン」「信頼ストア」「登録局」という用語名自体は、SGシラバスVer.4.1の公開鍵基盤の用語例には明示されていません。本記事では、PKI、各種証明書、トラストアンカー、CRLを理解するための関連知識として扱います。

2．デジタル証明書：主体の識別情報と公開鍵を結び付ける

デジタル証明書は、公開鍵証明書とも呼ばれます。

一般的な公開鍵証明書には、主体・公開鍵・発行者・シリアル番号・有効期間などの情報が含まれます。証明書の種類や拡張によって、対象名や鍵用途などの項目は異なります。

• 証明書の対象となる主体
• 主体の公開鍵
• 証明書を発行した認証局
• シリアル番号
• 有効期間
• サーバ証明書における接続先名など、用途に応じた対象情報
• 公開鍵の利用目的を示す情報（設定される場合）
• 証明書を発行した認証局のデジタル署名

認証局の署名を検証することで、証明書が発行後に改ざんされていないことと、対応する署名鍵を持つ認証局によって署名されたことを確認できます。

証明書に秘密鍵は含まれない

証明書に含まれるのは公開鍵です。

対応する秘密鍵は、証明書の対象となるサーバ・利用者などが別に管理します。

したがって、次の説明は誤りです。

サーバ証明書に含まれる秘密鍵と、サーバが持つ秘密鍵の一致を確認する。

証明書には秘密鍵を含めません。

TLS（Transport Layer Security）などでは、サーバが証明書内の公開鍵に対応する秘密鍵を保持していることを、プロトコル上の署名などによって示します。

証明書が単独では保証しないこと

証明書は、所定の確認手続に基づいて、主体の識別情報と公開鍵の対応を支えます。

一方、証明書が存在するだけで、次が無条件に保証されるわけではありません。

• 所有者が現在も同じ役職・権限を持つこと
• 証明書を使用した処理が本人の意思によること
• 秘密鍵が絶対に漏えいしていないこと
• Webサイト・文書の内容が正しいこと
• 接続先サービスが業務上信頼できること
• 契約・取引が法的に有効であること

証明書は重要な判断材料ですが、業務上の権限確認、承認手続、内容の確認を代替するものではありません。

3．認証局：証明書を発行・署名・管理する

認証局はCertification Authorityの略で、CAとも呼ばれます。

主な役割は次のとおりです。

• 証明書申請に対する確認
• 確認結果に基づく証明書の発行
• 発行証明書へのデジタル署名
• 証明書・シリアル番号の管理
• 証明書の失効処理
• CRLの発行
• 認証局自身の秘密鍵の厳重な管理
• 証明書ポリシー・運用規程に基づく運用

PKIによっては、申請者の本人・組織確認を登録局が担当し、認証局が発行・署名を担当する場合があります。

試験では、役割分担の細部より、次を押さえます。

認証局は、確認手続に基づいて主体と公開鍵を結び付けた証明書を発行し、証明書へ署名する。

認証局の秘密鍵が漏えいすると、偽の証明書を発行されるなど、広い範囲に影響する可能性があります。そのため、認証局の鍵は特に厳重に管理されます。

4．ルート証明書とトラストアンカー

証明書チェーンを検証するには、どこかにあらかじめ信頼する基点が必要です。

この信頼の基点をトラストアンカーといいます。

OS、ブラウザ、アプリケーション、組織の管理者などは、信頼する認証局の情報を信頼ストアへ登録します。

一般的な実装では、ルート認証局の自己署名証明書が、トラストアンカーを表すルート証明書として登録されます。

自己署名だから信頼されるのではない

ルート証明書は一般に自己署名されています。

しかし、自己署名されているという事実だけで信頼できるわけではありません。攻撃者も自己署名証明書を作成できます。

ルート証明書が信頼される理由は、次のような管理を通じて、信頼ストアへ安全に登録されているためです。

• OS・ブラウザ提供者による審査・配布
• 組織の管理者による承認・配布
• 管理された端末設定
• 信頼ストア変更権限の制限
• 不要・危険なルート証明書の削除

自己署名は証明書の形式を表すもので、信頼そのものは配布・登録方針によって与えられます。

偽のルート証明書を登録すると何が起こるか

攻撃者のルート証明書を信頼ストアへ登録すると、そのルートからつながる偽証明書を端末が信頼する可能性があります。

そのため、利用者が警告を回避する目的で、出所不明のルート証明書を安易に登録してはいけません。

5．中間CA証明書を利用する理由

多くのPKIでは、ルート認証局が全てのサーバ・利用者証明書を直接発行するのではなく、中間認証局を利用します。

一般的な階層は次のとおりです。

1. トラストアンカー・ルート認証局
2. 一つ又は複数の中間認証局
3. Webサーバ・利用者・端末などのエンドエンティティ

上位の認証局が下位の認証局又はエンドエンティティの証明書へ署名します。

中間認証局を利用すると、次のような管理が可能になります。

• ルート認証局の秘密鍵を日常運用から分離する
• 用途・組織ごとに証明書発行を分ける
• 認証局の運用権限を分離する
• 問題発生時の影響範囲を中間認証局単位で管理する
• 証明書ポリシー・名前・用途などの制約を設定する

ただし、中間認証局の秘密鍵が漏えいすれば、その認証局が発行できる範囲へ大きな影響が生じます。

6．証明書チェーンの検証

Webサーバ証明書を例にすると、一般的な証明書列は次のようになります。

信頼するトラストアンカー → 中間CA証明書 → Webサーバ証明書

証明書の発行では、上位の認証局が下位の証明書へ署名します。

• ルート認証局が中間CA証明書へ署名する
• 中間認証局がWebサーバ証明書へ署名する

検証では、対象証明書の発行者をたどり、信頼するトラストアンカーを基準として、各証明書の署名・制約が正しいかを確認します。

「上から下へだけ検証する」「下から上へだけ検証する」と処理順を固定して暗記するより、次を押さえることが重要です。

発行者の公開鍵で下位証明書の署名を検証し、信頼するトラストアンカーまで有効な連鎖が成立するかを確認する。

署名の向きを逆にしない

次の説明は誤りです。

中間CA証明書が、Webサーバ証明書によって署名されていることを確認する。

正しくは、中間認証局がWebサーバ証明書へ署名します。

下位のサーバ証明書が、上位の中間CA証明書へ署名するわけではありません。

7．証明書チェーン以外にも確認する項目

署名の連鎖が正しいだけでは、証明書を目的どおりに信頼できるとは限りません。

代表的な確認項目は次のとおりです。

有効期間

検証対象時点が、証明書の有効期間内か確認します。

有効期間が始まる前や、満了後の証明書を、新たな接続・認証に使用してはいけません。

対象名

Webサーバ証明書では、接続しようとしているサーバ名と、証明書に示された対象名が一致するか確認します。

信頼できる認証局が発行した有効な証明書でも、別のサーバ名向けであれば、その接続先の証明書としては適切ではありません。

鍵用途

証明書の公開鍵が、サーバ認証、クライアント認証、デジタル署名など、目的とする用途へ使用できるか確認します。

失効状態

有効期間内でも、秘密鍵の漏えい、退職、誤発行などによって失効している場合があります。

有効期間の確認と、失効状態の確認は別です。

証明書の制約

中間CA証明書では、認証局として下位証明書を発行できるか、名前・用途・証明書列の長さなどに制約がないかを確認する場合があります。

SGでは個別拡張の暗記より、証明書には用途・制約があり、署名の連鎖だけでは不十分であると理解します。

8．サーバ証明書とクライアント証明書

証明書は、何を証明する相手として使うかによって使い分けます。ここでは代表的な二つを比べます。

サーバ証明書

サーバ証明書は、主にサーバ名などの識別情報と公開鍵を結び付けます。

TLSでは、接続先サーバの認証に利用され、安全な通信を確立する処理の一要素となります。

証明書には公開鍵が含まれ、対応する秘密鍵はサーバ側で管理します。

クライアント証明書

クライアント証明書は、利用者、端末、組織などの識別情報と公開鍵を結び付けます。

• VPN（Virtual Private Network）接続
• 相互TLS
• 社内システムへの利用者・端末認証
• 電子申請などの本人・端末確認

などに利用されます。デジタル署名に用いる証明書との共通点はありますが、本記事ではクライアント認証用途を中心に扱います。

証明書を使用していても、秘密鍵がコピーされたり、退職者の証明書が有効なまま残ったりすれば、不正利用される可能性があります。

クライアント証明書は、アカウント管理、秘密鍵保護、失効処理と組み合わせます。

9．有効期間満了と証明書失効

証明書には有効期間があります。

有効期間満了は、証明書に設定された終了時点を迎えることです。

一方、証明書失効は、有効期間が残っていても、証明書を期限前に無効として扱う処理です。

主な失効理由

• 対応する秘密鍵の漏えい又は漏えいの疑い
• 退職・契約終了などにより、その証明書を継続利用すべきでなくなった
• 証明書に記載・前提とされた所属や名称などが変わった
• 証明書の誤発行
• 認証局・証明書利用者の運用停止
• 証明書情報が正しくなくなった
• 認証局自体の危殆化

期限まで待つと、その間に不正利用される可能性があります。

不要又は安全でなくなった証明書は、有効期間内でも速やかに失効させます。

10．退職者のクライアント証明書

退職者がVPN接続に使用していたクライアント証明書を考えます。

次の対応だけでは不十分です。

• 証明書の有効期限が切れるまで待つ
• 次回更新時に停止する
• VPNの共通パスワードだけを変更する
• 端末上の証明書ファイルだけを削除する

証明書と秘密鍵が別の場所へコピーされている可能性があるためです。

基本的な対応は次のとおりです。

1. クライアント証明書を失効させる
2. VPN・対象システムのアカウントを無効化する
3. 認証時に失効状態が確認されることを確認する
4. 端末・媒体から秘密鍵を安全に削除する
5. 必要に応じてアクセスログを確認する
6. 他の認証情報・権限も回収・停止する

証明書の失効だけでなく、アカウント・権限・端末を含む退職者管理が必要です。

11．CRL：失効した証明書を確認する

CRLはCertificate Revocation Listの略で、日本語では証明書失効リストといいます。

認証局又はCRL発行者が発行し、有効期間の途中で失効した証明書を識別するために使用します。

一般的なCRLには、次のような情報が含まれます。

• 失効した証明書のシリアル番号
• 失効日時
• 失効理由（記録される場合）
• CRLの発行時刻
• 次回更新予定時刻
• CRL発行者の情報
• CRL発行者のデジタル署名

証明書を利用する側は、適切なCRLを取得し、対象証明書が失効リストへ掲載されていないか確認します。

CRLも検証する

CRL自体を無条件に信頼してはいけません。

次を確認します。

• 正しい発行者の署名が付いているか
• CRL発行者を信頼できるか
• 対象証明書を扱うCRLか
• 十分に新しいCRLか
• 次回更新予定時刻を過ぎていないか
• 差分CRLなどを利用する構成では必要な情報がそろっているか

SGでは、細かなCRL拡張より、失効リストも署名・有効性・新しさを確認することを押さえます。

CRLの注意点

CRLは一定間隔で発行・更新されるため、失効を決定してから最新CRLへ反映され、利用者が取得するまでに時間差が生じる場合があります。

また、多数の証明書が失効している場合、リストの取得・処理負荷が大きくなる可能性があります。

それでも、SGでは証明書の期限前失効を確認する基本的な仕組みとしてCRLを理解します。

12．秘密鍵が危殆化した場合

証明書に対応する秘密鍵が漏えいした、又は漏えいした合理的な疑いがある場合は、鍵を使い続けてはいけません。

基本的な対応

1. 該当秘密鍵の利用を停止する
2. 対応する証明書の失効を申請・実施する
3. 最新のCRLへ失効が反映され、利用側で確認できることを確認する
4. 不正利用と影響範囲を調査する
5. 漏えい原因を除去する
6. 安全な環境で新しい鍵ペアを生成する
7. 新しい証明書を取得・配布する
8. 接続先・検証者の設定を必要に応じて更新する
9. 関係者へ必要な通知を行う

パスワード変更だけでは解決しない

秘密鍵ファイルの利用を保護するパスワードを変更しても、攻撃者が秘密鍵を既にコピーしていれば、コピーされた鍵を無効化できません。

また、元の端末から秘密鍵を削除しても、別の場所に残るコピーの利用を止められません。

証明書を失効させ、検証・認証を行う側が失効状態を確認する必要があります。

新しい証明書だけ取得しても不十分

旧証明書を失効させず、新しい証明書を追加するだけでは、漏えいした旧秘密鍵が引き続き利用される可能性があります。

次の両方が必要です。

• 旧証明書を無効として周知する失効
• 新しい鍵ペア・証明書への移行

13．認証局の秘密鍵が危殆化した場合

認証局の秘密鍵が漏えいすると、その認証局が発行したように見える不正な証明書が作成されるなど、配下へ広い影響が及ぶ可能性があります。

そのため、認証局証明書の信頼停止、配下証明書の再発行、信頼ストアやシステム設定の更新など、大規模な対応が必要になる場合があります。

SGでは、利用者やサーバの秘密鍵漏えいより影響範囲が広くなり得ることを理解する程度にとどめます。

14．科目Bでの使われ方

科目Bでは、証明書の内部構造ではなく、証明書を根拠にした判断が、どこまで確認したうえでのものかを問う形で使われます。

事例文に次の言葉が出てきたら、この記事の内容が判断材料になります。

担当者としては、証明書に関する事象が起きたら、署名の連鎖・有効期間・対象名・鍵用途・失効状態のどれをまだ確認していないかを切り分けます。秘密鍵の漏えいが疑われる場合は、まず該当鍵の利用を停止し、上位者や関係部署へ連絡して指示を仰ぎます。認証局や委託先の運用に関わる場合は、契約担当者と協力して対応します。

15．証明書の妥当性を見分ける手順

1. 公開鍵と誰を結び付けたいか確認する

主体の識別情報と公開鍵を結び付けるのがデジタル証明書です。

1. 証明書を誰が発行・署名したか確認する

発行者である認証局の署名を確認します。

1. 発行者を信頼できるか確認する

中間CA証明書をたどり、信頼するトラストアンカーまで連鎖が成立するか確認します。

1. 署名の向きを逆にしていないか確認する

上位の認証局が下位の証明書へ署名します。

1. 有効期間・対象名・鍵用途を確認する

署名の連鎖だけで判断しません。

1. 有効期間内でも失効していないか確認する

CRLを用いて、期限前に無効化された証明書を確認します。

1. 秘密鍵漏えい時にパスワード変更だけで済ませていないか確認する

証明書失効、新しい鍵ペア、影響調査が必要です。

1. 退職者の証明書を期限まで残していないか確認する

証明書・アカウント・権限を速やかに停止します。

1. ルート証明書を自己署名だから信頼していないか確認する

信頼は、信頼ストアへの安全な登録・管理に基づきます。

よくある取り違え

まとめ

• PKIは、公開鍵を信頼して利用するための技術・組織・運用を含む基盤
• デジタル証明書は、主体の識別情報と公開鍵を結び付ける
• 証明書には公開鍵、主体情報、発行者、有効期間などが含まれ、種類・拡張に応じて対象名や鍵用途なども示される
• 証明書に秘密鍵は含まれず、対応する秘密鍵は主体側で管理する
• 認証局は、確認手続に基づいて証明書を発行・署名し、失効・CRLを管理する
• トラストアンカーは証明書チェーンを検証する信頼の基点
• ルート証明書は一般に自己署名だが、自己署名だから信頼されるわけではない
• 信頼は、OS・ブラウザ・組織などの信頼ストアへ安全に登録・管理されることで与えられる
• 中間CA証明書を利用すると、ルート認証局の鍵を日常運用から分離し、用途・組織ごとに発行を管理できる
• 上位認証局が下位証明書へ署名し、対象証明書から信頼するトラストアンカーまで連鎖を確認する
• 証明書検証では、署名、チェーン、有効期間、対象名、鍵用途、失効状態を確認する
• 有効期間内でも、秘密鍵漏えい、退職、誤発行などによって証明書を失効させる場合がある
• CRLは、有効期間の途中で失効した証明書を識別するための署名付きリスト
• CRLも、発行者、署名、対象、新しさを確認する
• 秘密鍵漏えい時は、鍵の利用停止、証明書失効、影響調査、新しい鍵ペア・証明書への移行を行う
• パスワード変更や端末からの鍵削除だけでは、コピー済み秘密鍵を無効化できない
• 退職者のクライアント証明書は期限を待たず、アカウント・権限とともに停止する
• 証明書は主体と公開鍵の対応を支えるが、本人の意思、業務上の権限、内容の真実性を無条件に保証しない
• 科目Bでは、署名の連鎖だけでなく、失効・用途・対象名・鍵管理まで確認する

関連記事

• C2-T01：暗号方式の基本（鍵管理・危殆化を含む）
• C2-T03：ハッシュ関数とメッセージ認証
• C2-T04：デジタル署名とタイムスタンプ
• C2-T06：利用者認証の3要素と生体認証
• C2-T07：認証方式の仕組み
• C5-T06：アクセス制御と権限管理
• C5-T11：セキュアプロトコルと実装技術
• C8-T06：通信・電子取引に関する法律

本記事は、2026年8月3日時点のSGシラバスVer.4.1を基準に作成しています。

参考資料

• IPA「情報セキュリティマネジメント試験（レベル2）シラバス Ver.4.1」
• RFC 5280「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile」
• RFC 6818「Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile」
• RFC 10007「Clarification to Processing Key Usage Values During Certificate Revocation List (CRL) Validation」

関連する問題

• 情報セキュリティマネジメント 暗号・認証・PKI 択一式（応用） 第6問〜第10問
• 情報セキュリティマネジメント 暗号・認証・PKI 択一式（応用） 第16問〜第20問
• 情報セキュリティマネジメント 暗号・認証・PKI 一問一答 第16問〜第20問

---