図解でわかる、デジタル証明書の各局｜CA・RA・VAの役割と覚え方

目次

デジタル証明書は「相手と公開鍵の対応」を証明する

ここでいうデジタル証明書は、人・組織・サーバーなどと、その公開鍵を結び付ける公開鍵証明書です。代表的な形式がX.509です。

たとえば、HTTPSで使うサーバー証明書には、対象のドメイン名、公開鍵、発行者、有効期間などが入っています。認証局がその内容にデジタル署名を付け、利用する側が発行者と内容を検証できるようにします。[1]

この仕組みを支えるのが、PKI（Public Key Infrastructure：公開鍵基盤）です。直訳すると「公開鍵のための基盤」。証明書を作るだけでなく、申請の審査、発行、配布、失効、検証まで含みます。[2]

証明書は公開してよい情報であり、証明書の持ち主の秘密鍵は含みません。また、証明書があるだけで、Webサイトの内容や運営者のすべてが安全だと保証されるわけではありません。

CA・RA・VAの正式名称と、直訳からの覚え方

末尾のAuthorityは、単語としては「権威」「権限」という意味です。この文脈では、その仕事を行う権限・責任を持つ機関と読むと理解しやすくなります。「局」は日本語での慣用的な呼び方です。

以下の直訳は、英語を覚えるための説明です。規格で定められた日本語訳という意味ではありません。

略称・日本語名	英語の正式名称	直訳に近い意味
CA：認証局	Certification Authority	認証を行う権限を持つ機関
RA：登録局	Registration Authority	登録を行う権限を持つ機関
VA：検証局／有効性検証局	Validation Authority	有効性を確認する権限を持つ機関

CAは、資料によってCertificate Authorityとも表記されます。Certificateは「証明書」、Certificationは「認証・証明すること」。この記事では、IETFの仕様に合わせてCertification Authorityを使います。[2][3]

RA：Registrationは「登録」――申請を審査する

RAは、証明書の発行申請を受け付け、申請者や申請内容を確認する役割です。「この名前・公開鍵の組合せについて、証明書を発行してよいか」を審査し、結果をCAに伝えます。[4]

確認内容は証明書の種類や運用方針によって異なります。個人向けなら身元、サーバー向けならドメインの管理権限などが対象になります。すべての証明書で、個人の身分証まで確認するわけではありません。

運用によっては、更新や失効の申請もRAが受け付けます。RAは「登録の入口と審査担当」と覚えます。[4]

CA：Certificationは「認証」――署名して発行する

CAは、審査結果などに基づいて証明書を発行し、発行した証明書の失効などを管理する役割です。証明書には、発行するCAの秘密鍵によるデジタル署名が付きます。[1]

受け取った側は、そのCAの公開鍵を使って署名を検証します。署名する鍵と、証明書に載せる鍵を区別しましょう。

鍵	この場面での使い道
CAの秘密鍵	証明書に署名する
CAの公開鍵	その署名を検証する
申請者の公開鍵	発行された証明書の中に入る
申請者の秘密鍵	申請者が保持し、対応する公開鍵と組にして使う

CAは「証明書に署名する発行担当」です。ここで行うデジタル署名は、証明書の内容を秘密にする暗号化とは目的が違います。

VA：Validationは「有効性の確認」――利用時の問い合わせに応答する

VAは、証明書の有効性を確認するためのサービスを提供します。特に、その証明書が失効しているかという問い合わせと結び付けると覚えやすくなります。[3][5]

Registrationは「登録」、Validationは「有効性の確認」。似た略語でも、RAは主に申請時、VAは主に証明書を利用するときに登場します。

VAとOCSPレスポンダーは、文脈によって重なる呼び方です。ただし、VAは検証サービスの役割を表し、OCSPレスポンダーはOCSPという方式で状態を返すサーバーを指します。

CA・RA・VAは機能の分担です。必ず別々の会社や3台のサーバーになるわけではありません。 CAがRAの機能を兼ねる構成もあります。[2]

図解1：証明書を発行する流れ

以下は、申請者が自分で鍵ペアを生成し、RAとCAを分ける構成の例です。図の矢印は処理の順序を表し、実際の通信経路をすべて示すものではありません。

1. 申請者が秘密鍵・公開鍵のペアを生成する
2. RAが、公開鍵を含む申請と必要な情報を審査する
3. CAが、申請者の公開鍵などを含む証明書に署名して発行する
4. 申請者が証明書を受け取り、秘密鍵と組み合わせて使う

発行申請でよく出てくるCSR（Certificate Signing Request：証明書署名要求）は、「証明書に署名して発行してください」という依頼です。代表的なPKCS #10形式では、公開鍵や申請情報を入れ、申請者の秘密鍵で署名します。秘密鍵そのものを送る必要はありません。 この署名は鍵の所持を確認する材料になり、申請者の身元確認は別に必要です。[6]

図解2：証明書を使う側が確認すること

証明書を受け取ったブラウザーやアプリは、複数の条件を確認します。VAへの問い合わせが、すべての確認を置き換えるわけではありません。

確認すること	確かめたい内容
署名と信頼のつながり	信頼する発行元にたどれるか。署名が正しいか
有効期間	まだ開始前ではないか。期限切れではないか
接続先名・用途	HTTPSなら接続先名と合っているか。目的に使える証明書か
失効状態	期限内でも、途中で利用を取り消されていないか

HTTPSでは、証明書に示された名前と、接続しようとしたサーバーの名前が一致することも必要です。[7]

失効状態の確認方法には、主にCRLとOCSPがあります。図は、OCSPで直接問い合わせる場合の例です。実装によってはCRLを取得したり、サーバーが添付したOCSP応答を使ったりします。ブラウザーが毎回VAに直接問い合わせるとは限りません。

図解3：期限内の証明書を失効させる流れ

証明書が発行された後に、対応する秘密鍵が漏えいしたとします。有効期間が残っていても、その証明書を引き続き信用するのは危険です。そこで行うのが失効（revocation）です。[2]

失効しても、配布済みの証明書ファイルを世界中の端末から回収するわけではありません。失効情報を公開・提供し、証明書を利用する側が確認できるようにします。

CAが失効を管理し、RAは申請確認を担当し、VAは反映された状態を問い合わせ元に伝える、と分けて考えます。CRLの発行は通常CAが行いますが、別の発行者に委任する構成もあります。[2][4]

CRLとOCSPの正式名称・直訳

略称	正式名称	直訳・日本語名
CRL	Certificate Revocation List	証明書の失効リスト／証明書失効リスト
OCSP	Online Certificate Status Protocol	オンライン証明書状態プロトコル（通信規約）

CRLは一覧を取得して照合する方式です。対象の証明書のシリアル番号が失効リストに載っているかを確認します。リストの署名や対象範囲、更新時刻も確認する必要があります。

OCSPは、対象の証明書の状態を問い合わせ、署名付きの応答を受け取る方式です。代表的な状態は、次の3つです。[8]

状態	学習用の意味
good	失効状態について肯定的な応答。失効していないことを示す
revoked	失効として扱うべき状態
unknown	その応答者では状態を判断できない

goodは「証明書全体が有効・安全」という保証ではありません。 RFC 6960では、goodだけで発行済みであることや有効期間内であることまで保証しないとされています。署名、期限、接続先名などは別に確認します。また、応答の署名・署名者の権限・鮮度も重要です。[8]

CRLは更新周期、OCSPは状態情報や応答の更新・キャッシュに左右されます。「問い合わせたから必ず、その瞬間の最新情報」とは限りません。

ルートCA・中間CAと、補足して覚えたい局

ルートCAと中間CAは、どちらもCA

Root CAのRootは「根」、Intermediate CAのIntermediateは「中間」です。これはRA・VAのような役割分担ではなく、CAの階層上の位置を表します。

一般的なWeb PKIでは、ルートCAを信頼の起点とし、その下の中間CAがサーバー証明書などを発行します。利用側は証明書の署名を順に確認し、OSやブラウザーなどが信頼する起点にたどれるかを確認します。[1]

ルート証明書は通常自己署名ですが、自己署名だから信用できるのではありません。 そのCAの公開鍵などが、利用側であらかじめ信頼の起点として受け入れられていることが重要です。[2]

IAはCAの発行機能、TSAは時刻の証明

略称・日本語名	正式名称	直訳に近い意味・役割
IA：発行局	Issuing Authority	発行する権限を持つ機関。CAの業務を細分化したとき、証明書の生成・署名・発行などを担当する
TSA：時刻認証局	Time Stamping Authority	時刻の印を付ける権限を持つ機関。データのハッシュ値と時刻を結び付けた、署名付きのタイムスタンプを発行する

IAのIssuingは「発行すること」。資料によっては、CAの業務をRA・IAなどに分けて説明します。その場合、この記事で「CAが署名して発行する」と書いた具体的な処理をIAが担当します。CAとIAを常に別々の機関として数える必要はありません。[3][9]

TSAは、あるデータがその時刻までに存在していたことを証明するための局です。CAの階層上の上位・下位ではなく、電子署名などと組み合わせる別の役割です。証明書の有効期間内に署名が存在したことを検証する際の材料にもなります。[10]

勉強用：役割を言葉で説明できるか

次の問いは、この記事の内容を復習するためのものです。過去問の転載ではありません。

1. 証明書の発行申請を受け付け、申請者や申請内容を審査する局は？
2. 証明書にデジタル署名を付けるとき、誰のどの鍵を使う？
3. 証明書の失効状態などの問い合わせに応答する局は？
4. 有効期限内の証明書でも、失効することはある？
5. OCSPのgoodが返れば、証明書の期限や接続先名の確認を省略できる？
6. ルートCAとRAは、どちらも「Root」の略？

答えと覚え方を開く

1. RA。Registration＝登録。申請の入口と審査担当。
2. 発行するCAの秘密鍵。利用側は、そのCAの公開鍵で署名を検証する。
3. VA。Validation＝有効性の確認。OCSPではレスポンダーが状態を返す。
4. ある。秘密鍵の漏えいなどで、期限を待たずに利用を取り消す。
5. 省略できない。goodは失効状態についての応答であり、証明書のすべての条件を保証しない。
6. 違う。Root CAは「根に位置するCA」。RAのRはRegistration。

最後に、略語を役割とセットで声に出してみます。

Registrationで申請を審査。Certificationで署名して発行。Validationで利用時の確認。

参考資料

本文と図は、以下の公式資料・仕様をもとに学習用に整理しました。図は本記事用に作成し、通信や運用の細部を省略しています。英語の直訳・覚え方は本記事の補助説明です。

1. Microsoft Learn：Certification Authority role service ― CAの発行・失効、CAの階層と鍵
2. IETF：RFC 5280 ― PKIの構成、公開鍵証明書、失効、信頼の起点
3. JNSA：署名保証ガイドライン 第1.00版 ― CA・RA・IA・VAの用語定義（本文64ページ）
4. IETF：RFC 3647 §1.6 ― RAの申請審査・更新・失効に関する役割
5. Keyfactor：Setting up a Validation Authority (VA) ― VA、CRL、OCSPの構成例
6. IETF：RFC 2986 ― PKCS #10の証明書発行要求
7. IETF：RFC 9525 ― TLSでの接続先名の検証
8. IETF：RFC 6960 §2 ― OCSPの応答、good・revoked・unknownの意味
9. JPRS用語辞典：IA（Issuing Authority：発行局） ― CAの発行機能を分けるときの名称
10. IETF：RFC 3161 ― TSAとタイムスタンプ