インターネット上で安全に通信するには、通信相手が本当に信頼できるかを確認する「認証」が欠かせません。その認証を支える中核的な仕組みが、PKI(公開鍵基盤)です。
PKIは、デジタル証明書の発行・管理を担うインフラストラクチャであり、オンラインバンキングや電子商取引など、日常生活を支える重要な技術です。しかし、CA・RA・CP・CPSといった専門用語が多く、それぞれの役割や相互関係を正確に理解するのは容易ではありません。
本記事では、PKIを構成する主要要素であるCA(認証局)、RA(登録局)、CP(証明書ポリシー)、CPS(Certification Practice Statement:認証局運用規程。証明書運用規定とも)について体系的に解説します。これらを理解することで、PKIがどのように信頼性を担保しているのか、その全体像が見えてくるはずです。用語の要点を短く押さえたい場合は、姉妹記事「PKIの要、CA・RA・CP・CPSを徹底解説!安全な通信を支える仕組みとは」もあわせてご覧ください。
この記事で学べること:
- CA(証明書の発行・署名・失効)とRA(申請受付・本人確認)の役割分担
- CP(何を満たすか=What)とCPS(どう実施するか=How)の違い
- ルートCA・中間CAによる証明書チェーンと、信頼の根拠となるルートストア
- CRLとOCSPの違いと、公開Web PKIでCRLへ回帰している現状
PKI(公開鍵基盤)の基本と3つの役割
PKI(Public Key Infrastructure:公開鍵基盤)とは、公開鍵暗号技術を活用してインターネット上での安全な通信を実現するための基盤システムです。デジタル証明書の発行・管理・配布・失効といった一連のプロセスを管理し、なりすまし・データ改ざん・否認といったセキュリティリスクを防止します。電子商取引、オンラインバンキング、企業間の電子契約など、現代のあらゆる場面で活用されています。
PKIが果たす3つの重要な役割

本人認証の実現 デジタル証明書に含まれる情報と電子署名によって、通信相手が本当に本人であることを確認します。なりすましを防ぎ、正当な相手との通信を保証します。
改ざん検知の実現 送信者が自分の秘密鍵で作成したデジタル署名を、受信者は受信データ・署名・送信者の公開鍵(証明書に含まれるもの)を使って署名を検証します。検証に失敗した場合は改ざんなどの可能性があり、受信データの完全性と署名の真正性を確認できません(公開鍵の取り違えや署名の形式の不正でも失敗します)。RSA署名の代表的な説明では、署名から取り出したハッシュ値と受信データから計算したハッシュ値を比較すると表現されます(ECDSAやEdDSAは、ハッシュ値を取り出して比べる形ではなく、別の検証式で確かめます)。ハッシュ値を単体で送るだけでは、改ざんした人がハッシュ値も計算し直せるため不十分です。署名の検証とハッシュ関数の詳細は「デジタル署名で改ざんを検知する仕組みとは」「データの改ざんを確実に見抜く技術「ハッシュ関数とMAC」完全解説」で解説しています。
否認防止の実現 デジタル署名は署名者の秘密鍵でしか作れないため、誰が署名したかの証拠になり、後から「送っていない」と否定しにくくなります。ただし署名だけでは「いつ」署名したかは示せないため、時刻の証明にはタイムスタンプを組み合わせます。日本の電子署名法第3条は、電磁的記録であって情報を表すために作成されたもの(公務員が職務上作成したものを除く)について、本人による電子署名(本人だけが行うことができるものに限る)が行われているときは、真正に成立したものと推定すると定めています。
これらの役割はすべて、信頼できる第三者機関である認証局(CA)が発行するデジタル証明書によって実現されています。
テンプレート集
+おまけ:毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。
PKIを構成する6つの重要な要素
PKIの主要構成要素

PKIは複数の要素が有機的に連携することで機能します。各要素の役割を整理しておきましょう。
| 要素 | 正式名称 | 役割の概要 |
|---|---|---|
| CA | Certification Authority(認証局) | デジタル証明書の発行・管理を行う中核機関 |
| RA | Registration Authority(登録局) | 証明書の発行申請受付と本人確認を担う機関 |
| リポジトリ | — | デジタル証明書やCRLを保管・公開する場所 |
| エンドエンティティ | — | 証明書を実際に利用するユーザーやサーバー |
| CP | Certificate Policy(証明書ポリシー) | 証明書の利用目的や適用範囲を定めた方針文書 |
| CPS | Certification Practice Statement(認証局運用規程) | CPの要件を満たすための具体的な運用手順を定めた文書 |
PKIの信頼モデル:階層構造による信頼の連鎖

PKIの信頼性は、CAの階層構造によって支えられています。
階層構造の頂点にはルートCAが存在します。ルートCAは上位のCAを持たないため、自分の秘密鍵で自分の証明書に署名した自己署名証明書を持ちます。ただし、自己署名は誰でも作れるため、それ自体は正当性の証明になりません。ルートCAを信頼できる根拠は、そのルート証明書がOSやブラウザのルートストアに信頼アンカーとして登録されていることです。社内のプライベートPKIでは、管理者がルート証明書を端末に配布・登録します。
ルートCAの下には中間CAが配置され、中間CAはルートCAによって正当性を証明されます。エンドエンティティが使用するデジタル証明書は、この中間CAによって発行されます。
「ルートCA → 中間CA → エンドエンティティ」という信頼の連鎖(証明書チェーン)が構築されることで、最終的な証明書の信頼性が担保されます。HTTPS接続の中でサーバー証明書がどう検証されるかは「図解でわかる!HTTPS(SSL/TLS)の接続フローとハンドシェイクの仕組み」で解説しています。この階層構造により、ルートCAが侵害されるリスクを最小化しながら、柔軟な証明書発行体制を実現しています。
CA(認証局)の3つの中核業務
CA(Certification Authority:認証局)は、PKIにおける信頼の起点となる機関です。デジタル証明書の発行から失効まで、証明書のライフサイクル全体に責任を持ちます。
1. デジタル証明書の発行
申請者の公開鍵や主体情報、有効期間などを含む証明書本体(TBSCertificate)に、CA自身の秘密鍵で署名して証明書を発行します。発行される証明書には以下の情報が含まれており、国際規格X.509に準拠した形式で作成されます。
- シリアル番号(CAが証明書ごとに割り当てる一意の番号。CRLで失効した証明書を特定する際に使う)
- 公開鍵
- 所有者情報(サブジェクト)
- 有効期限
- 発行者(CA)の情報
- CAのデジタル署名

2. デジタル証明書の管理
発行したすべての証明書を適切に管理します。具体的には以下の業務が含まれます。
- 証明書の有効期限の追跡と更新手続きの管理
- 失効要求の受付(秘密鍵の漏洩・登録情報の変更などを理由とする申し出)
- 公開TLSサーバー証明書の場合、Certificate Transparency(CT)ログへの登録
- CAの秘密鍵の危殆化など、セキュリティインシデント発生時の迅速な対応
3. CRL(証明書失効リスト)の発行と公開
秘密鍵の漏洩・証明書情報の誤り・不正使用などが判明した場合、該当する証明書を失効させ、その情報をCRL(Certificate Revocation List)として定期的に発行・公開します。これにより、第三者は失効した証明書を誤って信頼するリスクを回避できます。

CRLに加えて、OCSP(Online Certificate Status Protocol)という、個々の証明書の失効状態をリアルタイムに問い合わせる仕組みもあります。CRLが定期的に発行されるリストであるのに対し、OCSPは問い合わせに応じて個々の証明書のステータスを返します。ただしOCSPの応答も事前生成・キャッシュされ、次回更新時刻(nextUpdate)までは同じ応答が使われることがあるため、鮮度はレスポンダの運用・更新間隔によります。また公開Web PKIでは、2023年に採決されたBallot SC063による改定が2024年3月15日にBaseline Requirementsへ適用され、OCSPが任意・CRLが必須となり、Let's Encryptは2025年8月にOCSPレスポンダを停止するなど、CRLへ回帰する流れがあります。
CAはPKI全体の信頼性を左右する存在であるため、物理的セキュリティ・システムセキュリティ・運用プロセスのセキュリティなど、あらゆる面で最高レベルの対策が求められます。
RA(登録局)の3つの実務業務
RA(Registration Authority:登録局)は、CAの業務の一部を代行し、証明書発行プロセスをより効率的かつ安全にする役割を担います。
1. 申請の受付と初期審査
デジタル証明書の発行申請を受け付け、提出された書類・情報が形式要件を満たしているかを確認します。不備がある場合は申請者に修正を求め、審査の質を担保します。
2. 厳格な本人確認の実施
RAの最も重要な役割が本人確認です。証明書の種類や用途に応じた確認手続きを実施します。
サーバー証明書は、確認する範囲によって次の3つの検証レベルに分かれます。
- DV(Domain Validation):申請者がドメインの管理権限を持つことだけを確認する。組織の実在確認は行わない
- OV(Organization Validation):ドメインの管理権限に加え、組織の実在(登記事項証明書や第三者データベース等)と申請者の所属を確認する
- EV(Extended Validation):OVよりも厳格な審査基準で、組織の実在・所在地・申請者の権限などを確認する
これとは別に、個人を対象とする証明書(電子署名用など)では、運転免許証・パスポートなどの公的な身分証明書で本人確認を行います。
本人確認の厳格さが証明書の信頼性を直接左右するため、RAには高度な審査能力が求められます。
3. 審査済み申請情報のCAへの伝達
本人確認・審査が完了した申請情報をCAに伝達します。この際、RAは申請者の身元確認が適切に行われたことを証明する情報も併せて提供します。CAはRAから受け取った情報を信頼して証明書を発行するため、RAとCA間には強固な信頼関係が不可欠です。
CAとRAの連携プロセス

実際のデジタル証明書発行は、以下のような流れで進みます。
- 申請者がRAにデジタル証明書の発行申請を行う
- RAが申請を受け付け、必要書類の確認と本人確認を実施
- すべての審査をクリアしたRAが、申請情報をCAに伝達
- CAがRAからの申請情報に基づき証明書を生成し、自身の秘密鍵でデジタル署名を付与
- 完成した証明書を申請者に発行
このように役割を分担することで、CAは証明書の発行・管理という中核業務に専念でき、RAは地域や業界に特化した本人確認業務を効率的に担います。大規模なPKIでは複数のRAを配置することで、地理的に分散した申請者にも対応できる柔軟な体制を実現しています。
CP(証明書ポリシー)とCPS(認証局運用規程)の役割と違い
PKIの信頼性を客観的に評価し、利用者が安心して証明書を使用するためには、CAの運用方針と具体的な手順が明確に文書化されている必要があります。その役割を果たすのがCPとCPSです。
CP(証明書ポリシー)とは
CP(Certificate Policy:証明書ポリシー)は、デジタル証明書の利用目的・適用範囲・発行対象者・発行手続きの概要など、PKI運用における基本方針を定めた文書です。証明書を利用する側にとって、その証明書がどの程度信頼できるか・どのような用途に適しているかを判断するための重要な情報源となります。
CPに記載される主な内容は以下のとおりです。
- 証明書の利用目的:SSL/TLS通信専用、電子メール署名専用、電子契約署名用など、用途を限定して適切な利用を促進
- 適用範囲:取得できる組織・個人の条件、地理的制限(法人のみか個人も対象か、特定業界限定かなど)
- 発行対象者の要件:法人格の有無、個人事業主の可否、年齢制限など
- セキュリティ要件:証明書の鍵長、有効期限、失効条件などの基本的なセキュリティ基準
有効期限の要件は短くなる方向にあります。CA/Browser ForumのBallot SC-081v3(2025年4月可決)により、公開TLSサーバー証明書の最長有効期間は、2026年3月15日以降の発行分は200日、2027年3月15日以降は100日、2029年3月15日以降は47日へと段階的に短縮されます。手作業での更新は現実的でなくなるため、更新の自動化が事実上必須になり、ACMEはその代表的な手段です。
CPS(認証局運用規程)とは
CPS(認証局運用規程)は、CPの要件を満たすためにCAが実際にどのようにデジタル証明書を発行・管理するかを詳細に記載した文書です。監査機関や規制当局がCAの運用を評価する際の基準ともなります。
CPSに記載される主な内容は以下のとおりです。
- 証明書発行の具体的な手順:申請受付から証明書発行までの各ステップ、必要書類、処理期間、承認プロセス
- 本人確認の方法:確認に使用する書類、対面確認の要否、オンライン確認の条件など
- 秘密鍵の管理方法:CAが使用する秘密鍵の生成方法・保管場所・アクセス制御。HSM(Hardware Security Module)の使用、複数人による管理(M-of-N方式の分散管理・キーセレモニー)、物理的なセキュリティ対策が記載される。鍵のライフサイクル全体の管理は「【完全攻略】公開鍵暗号の要!鍵管理とデジタル証明書(PKI)の仕組みと過去問対策」で解説しています
- セキュリティ対策:システム監査の方法、インシデント対応手順、バックアップ体制、災害復旧計画
- 証明書の失効手順:失効条件、失効要請への対応手順、CRLの発行頻度と公開方法
CPとCPSの関係:「What」と「How」の相互補完

CPとCPSは互いに補完し合う関係にあります。CPが「何をすべきか(What)」という方針レベルを定めるのに対し、CPSは「どのように行うか(How)」という実践レベルを定めています。
たとえば、CPで「本人確認を厳格に行う」という方針が定められている場合、CPSでは以下のような具体的手順が記載されます。
- 公的証明書の原本確認を対面で実施し、コピーを保管する
- 企業の場合は登記事項証明書の発行日が6ヶ月以内のものに限る
- 申請組織への所属確認は、人事部門への直接問い合わせにより実施する
CPは要件(What)を、CPSはそれを満たす詳細な手順(How)を開示する文書であり、一般にCPSのほうが詳細です。なお、公開TLSサーバー証明書を発行するCAは、Baseline Requirements(2.3節)によりCPまたはCPS(両方を持つ場合は両方)を少なくとも年1回更新することが求められ、内容に変更がなくても版番号と日付付きの変更履歴を更新します。
証明書を利用する側はCPを読むことでその証明書の用途や信頼レベルを理解でき、詳細な運用実態を確認したい場合はCPSを参照できます。このように、CPとCPSはPKIの透明性と信頼性を担保する「車の両輪」として機能しており、これらが適切に整備・遵守されることでPKI全体の信頼性が維持されます。
PKI全体像の整理:4要素の連携が信頼を生む
ここまで解説してきたCA・RA・CP・CPSの関係を改めて整理します。
| 要素 | 役割の性質 | 主な機能 |
|---|---|---|
| CA(認証局) | 信頼の起点 | 証明書の発行・管理・失効 |
| RA(登録局) | 審査の窓口 | 申請受付・本人確認・CAへの伝達 |
| CP(証明書ポリシー) | 方針の文書化 | 利用目的・適用範囲・信頼基準の定義 |
| CPS(認証局運用規程) | 運用の文書化 | 具体的な発行手順・管理方法、監査(WebTrust・ETSI等の基準)で準拠性を確認される運用内容 |
CAは信頼の起点として証明書のライフサイクル全体を管理し、RAはCAの負荷を分散しながら厳格な本人確認を担います。CPはPKI運用の基本方針を示し、CPSはその方針を実務レベルの手順へと落とし込みます。
この4要素が有機的に連携することで、PKIは機能します。私たちが日常的に利用しているHTTPS通信、電子契約、オンラインバンキング、リモートワークでのVPN接続など、現代社会のあらゆるデジタル活動はPKIによって支えられています。
PKIと証明書の信頼性を左右する要因
PKIの信頼性は技術的な仕組みだけでなく、運用面の品質にも大きく依存します。以下の要素が証明書の信頼性を直接左右します。
- RAの本人確認の厳格さ:確認が甘ければ、不正取得された証明書が出回るリスクが高まる
- CAの秘密鍵管理の堅牢さ:CAの秘密鍵が漏洩すれば、そのCA(と配下のCA)が発行した証明書全体の信頼性が失われ、攻撃者が偽の証明書を発行できるようになる
- CRLおよびOCSPの迅速な更新:失効情報の公開が遅れると、不正な証明書が使われ続けるリスクがある
- CPとCPSの適切な整備と遵守:文書が形骸化すれば、監査や第三者評価が機能しなくなる
これらの要素が揃って初めて、PKIは「信頼の基盤」としての役割を果たせます。
OCSPとCRLの使い分け
証明書の失効確認手段として、CRLとOCSPの2つが存在します。それぞれの特徴は以下のとおりです。
CRL(証明書失効リスト)
- 定期的に更新されるリスト形式
- 失効件数が増えるとリストが大きくなり、取得の負荷が増える。取得後は次の更新までローカルで照合できる
- 更新間隔があるため、失効直後の証明書を見逃す可能性がある
OCSP(Online Certificate Status Protocol)
- リクエストに応じてリアルタイムで証明書ステータスを返す
- 証明書ごとに状態を確認できる。ただし応答は事前生成・キャッシュされることが多く、鮮度はレスポンダの運用・更新間隔による(CRLより常に新しいとは限らない)
- 応答の状態は、未失効(good)・失効(revoked)・不明(unknown)の3つ。goodは失効していないことを示すだけで、有効期限・署名・証明書チェーンは別途検証が必要
- OCSPサーバーへのアクセスが必要であり、プライバシーの懸念もある
OCSPレスポンスをWebサーバーが事前に取得してTLSハンドシェイクで提示するOCSPステープリングという手法もあり、クライアントがOCSPレスポンダへ直接問い合わせずに済むため、性能とプライバシーの課題を緩和できます。ただし公開Web PKIでは、前述のとおりBaseline RequirementsでOCSPが任意・CRLが必須となり、Let's EncryptがOCSPレスポンダを停止するなど、CRLへ回帰する流れがあります。OCSPを提供しないCAの証明書では、OCSPステープリングも使えません。CRL・OCSP・OCSPステープリングの比較と過去問は「【SC試験】OCSPとCRLの失効確認はこう問われる」で詳しく解説しています。
SC試験での出題パターンと対策
PKIの構成要素は、科目A-2(旧午前II)で用語の定義を問う形で出題された例があります。いずれも「どの機関・文書・リストが、何を担うか」を正確に区別できるかが問われます。ここでは、IPAの公式解答で確認できる過去問4題の問われ方と押さえどころを整理します。
RAとCPSの定義を問う問題
令和4年度 秋期 午前II 問2では、RAの役割を選ばせる問題が出題されました。正解は「本人確認を行い、デジタル証明書の発行申請の承認又は却下を行う」です。失効リストの管理など、CAの業務を書いた選択肢が引っかけとして並びます。「RAは審査、CAは署名・発行・失効」と分担で覚えておくと迷いません。
令和5年度 秋期 午前II 問9では、CPSが何を定める文書かが問われました。正解は「認証局の認証業務の運用などに関する詳細を規定した文書」です。CP(方針・要件)と取り違えないよう、CPSは「運用の詳細(How)」と押さえておきます。
CRLとOCSPを問う問題
平成29年度 秋期 午前II 問1では、CRLに掲載される情報が問われました。正解は「有効期限内に失効したデジタル証明書のシリアル番号」です。CRLは失効した証明書を識別するためのリストであり、証明書の中身(公開鍵など)や有効期限切れの証明書を一覧にしたものではない、と押さえておきます。
平成29年度 秋期 午前II 問2では、OCSPを利用する目的が問われました。正解は「デジタル証明書の失効情報を問い合わせる」ことです。OCSPは証明書の失効状態を確認するためのプロトコルであり、証明書の発行や配布そのものを行う仕組みではない、と区別しておきます。
対策のポイント
- CA・RA・リポジトリの業務を、動詞(署名・発行・失効/審査・承認/公開)で区別する
- CPは方針・要件(What)、CPSは運用の詳細(How)と対で覚える
- CRLは「有効期限内に失効した証明書のシリアル番号の一覧」、OCSPは「個々の証明書の失効状態の問い合わせ」と定義の言い回しで押さえる
- ルートCAは自己署名証明書を持つが、信頼の根拠はルートストアへの登録であることも説明できるようにしておく
【演習】PKI理解度チェック(全10問)
科目A-2(旧午前II)では、RAとCAの業務の取り違えや、CPとCPSのどちらが運用の詳細を定めるか、CRLに何が載るかといった定義の区別が問われやすく、「RAが失効リストを管理する」「CPが運用手順を定める」といった役割を入れ替えた選択肢が定番の引っかけです。以下の練習問題で本記事の理解度を確認してみましょう。
まとめ:PKIの4要素が支えるデジタル社会の信頼
本記事では、PKI(公開鍵基盤)を構成する重要な要素であるCA(認証局)、RA(登録局)、CP(証明書ポリシー)、CPS(認証局運用規程)について解説しました。
- CAは、デジタル証明書の発行・管理・失効を行う信頼の起点。PKI全体の信頼性を支える中核的な存在
- RAは、証明書発行申請の受付と本人確認を担う機関。CAと連携することで、効率的かつ安全な証明書発行プロセスを実現
- CPは、デジタル証明書の利用目的や適用範囲などの基本方針を定めた文書。証明書の信頼性を判断するための指針
- CPSは、CPに基づいてCAが具体的にどのように証明書を発行・管理するかを詳細に定めた文書。運用の透明性と監査可能性を担保
これら4つの要素が有機的に連携することでPKIは機能し、私たちの日常を支える安全なデジタル通信が実現されています。
X.509の構造と証明書チェーンの検証手順は「デジタル証明書(X.509)の構造と検証プロセスを完全解説」で解説しています。
本記事は情報処理安全確保支援士(SC)試験対策を目的として作成しています。
参考資料
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
- RFC 3647: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
- RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
- CA/Browser Forum: Baseline Requirements
- Let's Encrypt: Ending OCSP Support in 2025
- IPA: 過去問題
- e-Gov法令検索: 電子署名及び認証業務に関する法律
テンプレート集
+おまけ:毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。