PUBLIC KEY INFRASTRUCTURE
CPSとは?電子証明書を発行する認証局のルールとCPとの違い
ネットショップのURLにある鍵マーク。ブラウザが接続先の証明書を信頼できるか判断する背景には、「証明書を誰が、どんな手順で発行したか」という運用の仕組みがあります。その説明書のひとつがCPS(Certification Practice Statement:認証局運用規程)です。
証明書は「発行した」だけでは信用できない
例えばネットショップ「さくら商店」が、ドメイン名 shop.example 用のサーバ証明書を申し込んだとします。発行者が相手の確認をせず、誰にでも証明書を発行するなら、偽サイトの運営者にも証明書が渡ってしまいます。
そこで証明書を発行する認証局(CA)は、申請内容を検証し、発行後も有効期限や失効情報を管理します。ブラウザの鍵マークは「通信が暗号化され、証明書の検証が通った」ことを主に示します。ショップ自体の評判や商取引の安全性まで保証するものではありません。
申請・確認
申請者が対象ドメインを管理していることなどを検証
発行・公開
CAが証明書に署名し、必要な情報を公開
運用・失効
有効期限、更新、秘密鍵漏えい時の失効に対応
CPとCPSの違い:ルールと実際の運用
認証局の文書には、よく似た略語が2つ登場します。CP(Certificate Policy:証明書ポリシー)とCPS(Certification Practice Statement:認証局運用規程)です。
CP / WHAT
何を満たすべきか
証明書の目的や要求水準など、参加者が守るべき条件を定める。
例:発行前にドメイン管理権限を確認すること。
CPS / HOW
どう実施するか
認証局が使う検証手順、鍵の管理、失効処理などの運用を説明する。
例:DNSへの指定値の登録を検証し、確認記録を保存する。
たとえるなら、CPは「入場には本人確認が必要」という規則で、CPSは「担当者が身分証をこの手順で確認し、記録をこの期間保管する」という業務手順です。ただし、CPとCPSは単なる上位文書・下位文書の関係だけではありません。1つのCPSが複数のCPに対応することも、異なる認証局が同じCPに対応することもあります。
CPSには何が書かれるのか
CPSが扱うのは、証明書の新規発行だけではありません。証明書のライフサイクル全体にわたり、組織が実施する対策や手続きを説明します。
| 運用項目 | 具体的に定めることの例 |
|---|---|
| 本人確認・ドメイン検証 | 申請者の確認方法、検証結果の記録方法 |
| 秘密鍵の管理 | CA秘密鍵の保護、操作権限、バックアップ・復旧 |
| 証明書の発行・更新 | 発行承認、更新条件、通知や公開の方法 |
| 失効(Revocation) | 失効申請の受付、判断、CRLやOCSPへの反映 |
| 監査・記録 | ログ保管、監査の実施、事故発生時の手続 |
操作ラボ:CPの約束がCPSの手順で守られるか
同じ証明書でも、認証局の運用が変わればリスクは変わります。以下のラボでは証明書の申請・鍵管理・失効対応を選択し、公開された運用方針と実際の対策に食い違いがないかを確認できます。
INTERACTIVE PKI LAB
認証局の運用を点検してみよう
これは架空の認証局「みどり認証局」の運用例です。各項目のCPS手順を安全なもの・危険なものに切り替え、CPの約束を守れるか確認します。実際の証明書発行や通信は行いません。
CP:満たすべき条件
ドメインの管理権限を確認してから発行する
CPS:実際の手順(選択可能)
DNSなどを使った管理権限の検証結果を記録する
証明書運用の流れ
この段階では、DNSなどを使った管理権限の検証結果を記録するという運用で方針に対応しています。
すべての運用例が方針に沿っています
ただし、この簡易確認だけで実際の認証局の安全性や適合性を保証できるわけではありません。
運用トラブルを考える:秘密鍵が漏れたら?
状況:ネットショップのサーバ秘密鍵が外部に漏えいした
このとき証明書の期限がまだ残っていても、安全とは限りません。事業者は秘密鍵と証明書を更新し、必要に応じて旧証明書の失効を申請します。CA側では、本人確認を含む失効申請の受付方法、処理時間、失効情報の公開手順などをCPSで説明します。
なお、ブラウザが証明書を受け入れるかどうかは、証明書チェーンの信頼、ホスト名、有効期限、ポリシー、失効情報など複数の要素で決まります。「CPSが存在するから無条件に安全」とは言えません。
認証局・登録局・監査機関は別の役割
CA(認証局)は証明書を発行・管理する主体です。RA(登録局)は申請受付や身元確認の一部を担う場合があります。監査機関は認証局の運用が基準に適合しているか検証する側です。CPSは通常、CAの運用実態を記述するものであり、申請者個人のセキュリティ宣言や監査会社の社内規程ではありません。
まとめ:電子証明書の「信頼」を支える運用の説明書
CPは求められる条件、CPSは認証局がその条件をどう実現するかを示します。証明書の暗号アルゴリズムが強固でも、申請確認や秘密鍵管理、失効の運用が甘ければ信頼を損ないます。電子証明書を導入・評価するときは、証明書そのものだけでなく発行元のCPとCPSにも目を向けることが重要です。
技術的な文書構成については、IETFの RFC 3647 が参考になります。