PKI・CA・RAとは？　～電子証明書を「申請するとき」と「使うとき」を初心者向けに整理する～

WebサイトをHTTPSで安全に通信したり、組織の利用者であることを証明したりするときに使われるのが、電子証明書です。

その電子証明書について勉強していると、次のような用語が出てきます。

• PKI

• CA

• RA

• 公開鍵

• 秘密鍵

• 電子署名

しかし、用語を一つずつ覚えても、

と混乱しやすいところです。

先に結論を言うと、CAやRAが主に登場するのは、電子証明書を申請・発行・管理するときです。

一方、電子証明書を実際の通信で使うときは、証明書を受け取った相手が、CAの電子署名などを確認します。

この記事では、PKIの全体像を、

1. 証明書を申請する

2. 証明書が発行される

3. 証明書を使う

4. 証明書を失効させる

という順番で整理します。

そもそも電子証明書とは

電子証明書は、簡単にいえば、

と証明する電子的な身分証明書です。

電子証明書には、主に次のような情報が入っています。

• 証明書の所有者

• 公開鍵

• 証明書の有効期限

• 証明書を発行したCA

• CAによる電子署名

たとえば、Webサイトの証明書であれば、

ということを証明します。

公開鍵だけを渡されても、それが本当に目的のWebサイトの公開鍵なのかは分かりません。

そこで、信頼できる第三者であるCAが、その公開鍵と所有者の関係を証明します。

PKIとは

PKIは、Public Key Infrastructureの略で、日本語では「公開鍵基盤」と呼ばれます。

PKIは、特定の一台の装置や一つの組織を指す言葉ではありません。

公開鍵暗号や電子証明書を安全に利用するための、次のような仕組み全体を指します。

• 公開鍵と秘密鍵

• 電子証明書

• CA

• RA

• 証明書の発行手続き

• 証明書の有効期限

• 証明書の失効管理

• 証明書を信頼するためのルール

つまりPKIとは、

です。

CAとRAの役割

CAとは

CAは、Certification Authorityの略で、日本語では「認証局」と呼ばれます。

CAの主な仕事は、電子証明書を発行することです。

ただし、単に証明書のデータを作るだけではありません。

CAは、証明書に対してCA自身の秘密鍵で電子署名を行います。

この電子署名によって、証明書を受け取った人は、

• 証明書がCAによって発行されたこと

• 証明書が途中で改ざんされていないこと

を確認できます。

CAの役割を簡単に表すと、

となります。

RAとは

RAは、Registration Authorityの略で、日本語では「登録局」と呼ばれます。

RAの主な仕事は、証明書を申請した人や組織の本人確認・審査を行うことです。

たとえば、証明書の申請者について、

• 本人であるか

• その組織に所属しているか

• そのドメインを管理する権限があるか

• 申請内容に誤りがないか

などを確認します。

審査に問題がなければ、RAはCAへ、

と伝えます。

RAは、証明書を申請する人とCAの間に立つ、受付・本人確認・審査担当のような存在です。

CAとRAの違い

CAとRAの違いを一言で表すと、次のようになります。

組織　　 主な役割
RA　　　申請者の本人確認・審査をする
CA　　　電子証明書を発行し、電子署名する

たとえるなら、パスポートの発行手続きに少し似ています。

窓口で本人確認や書類確認を行う担当がRA、正式なパスポートを発行する機関がCA、というイメージです。

ただし、実際の運用では、CAとRAを同じ組織が担当する場合もあります。

そのため、必ず別会社・別組織になっているとは限りません。

大切なのは組織名ではなく、

• 本人確認・審査

• 証明書の発行・署名

という役割が分かれていることです。

電子証明書を申請してから発行されるまで

ここからは、証明書の申請から発行までの流れを見てみます。

1. 公開鍵と秘密鍵を作る

まず、証明書を利用したい人やサーバは、公開鍵と秘密鍵のペアを作ります。

• 公開鍵：他人に渡してよい鍵

• 秘密鍵：本人だけが厳重に保管する鍵

この二つは、数学的に対応したペアになっています。

秘密鍵は非常に重要です。

秘密鍵が他人に盗まれると、本人になりすまして通信や電子署名を行われる可能性があります。

2. 証明書を申請する

申請者は、公開鍵や本人・組織に関する情報を含む申請データを作り、証明書の発行を申請します。

Webサーバ証明書の場合、この申請データは一般にCSRと呼ばれます。

CSRは、Certificate Signing Requestの略です。

CSRには、主に次のような情報が含まれます。

• 証明書に登録したいドメイン名

• 組織名などの申請情報

• 公開鍵

秘密鍵そのものをCAやRAへ送るわけではありません。

秘密鍵は申請者側で保管し、公開鍵を含むCSRを送ります。

3. RAが本人確認・審査をする

申請を受け取ったRAは、申請者や申請内容を確認します。

確認方法は証明書の種類によって異なります。

Webサイト向け証明書の場合は、たとえば、

• そのドメインを本当に管理しているか

• 申請した組織が実在するか

• 申請者が組織を代表して申し込む権限を持っているか

などを確認します。

証明書によっては、ドメインの管理権限だけを確認するものもあれば、組織の実在性まで詳しく確認するものもあります。

4. CAが電子証明書を発行する

RAによる確認が終わると、CAが証明書を発行します。

CAは、

• 申請者の情報

• 申請者の公開鍵

• 有効期限

• 発行者の情報

などをまとめた証明書を作り、CA自身の秘密鍵で電子署名します。

このCAの電子署名があることで、証明書を受け取った相手は、

と確認できます。

発行までの流れ

証明書の申請・発行の流れを簡単に表すと、次のようになります。

申請者
  │
  │ 公開鍵・申請情報を送る
  ▼
RA
  │
  │ 本人確認・審査
  ▼
CA
  │
  │ CAの秘密鍵で署名
  ▼
電子証明書を発行

ここまでが、主にCAとRAが活躍する場面です。

電子証明書を実際に使うとき

では、発行された電子証明書を実際の通信で使うときは、何が起きるのでしょうか。

ここでは、WebブラウザでHTTPSのWebサイトへアクセスする場合を例にします。

1. Webサーバが証明書を送る

ブラウザがHTTPSのWebサイトへ接続すると、Webサーバはブラウザへ電子証明書を送ります。

証明書には、Webサーバの公開鍵やドメイン名、CAの電子署名などが含まれています。

2. ブラウザが証明書を確認する

証明書を受け取ったブラウザは、主に次のような点を確認します。

• 接続先のドメイン名と証明書の内容が一致しているか

• 証明書の有効期限が切れていないか

• 信頼できるCAが発行した証明書か

• 証明書が改ざんされていないか

• 証明書が失効していないか

この確認が成功すれば、ブラウザは証明書に含まれる公開鍵を信頼できます。

3. CAの公開鍵で電子署名を検証する

証明書には、CAが秘密鍵で付けた電子署名があります。

ブラウザなどの利用者側は、CAの公開鍵を使って、その電子署名を検証します。

この検証により、

• 本当にCAが発行した証明書か

• 発行後に証明書が改ざんされていないか

を確認できます。

ここで重要なのは、証明書を使うたびに、RAが改めて本人確認をするわけではないという点です。

RAによる本人確認は、基本的には証明書を申請・発行するときに行われています。

利用時には、CAが付けた電子署名を検証することで、その確認結果を間接的に信頼します。

4. 安全な通信を開始する

証明書が正しいと確認できたら、その後はTLSの手続きによって安全な通信を開始します。

実際のデータ通信では、処理が高速な共通鍵暗号が主に使われます。

つまり、電子証明書や公開鍵暗号は、通信相手の確認や安全に鍵を共有するために使われ、その後の大量の通信には共通鍵暗号が使われます。

利用時の流れ

Webサーバ
  │
  │ 電子証明書を送る
  ▼
ブラウザ
  │
  ├─ ドメイン名を確認
  ├─ 有効期限を確認
  ├─ CAの署名を確認
  ├─ 証明書の失効を確認
  │
  ▼
証明書を信頼
  │
  ▼
TLSによる安全な通信を開始

「申請するとき」と「使うとき」を分けて考える

PKIを理解するうえで、最も大切なのがこの区別です。

証明書を申請・発行するとき

主に登場するのは、次の人や組織です。

• 証明書の申請者

• RA

• CA

この段階では、

• 申請者は本物か

• その公開鍵は誰のものか

• 証明書を発行してよいか

を確認します。

証明書を使うとき

主に登場するのは、次の二者です。

• 証明書を提示する側

• 証明書を確認する側

Web通信であれば、

• 証明書を提示する側：Webサーバ

• 証明書を確認する側：ブラウザ

です。

ブラウザは、CAの署名や有効期限などを確認し、証明書を信頼してよいか判断します。

二つの場面を並べると

場面　　　　　主な処理　　　　　　　　　　主な登場人物
申請・発行時　本人確認、審査、証明書発行　申請者、RA、CA
利用時　　　　証明書の検証、暗号通信　　　サーバ、ブラウザなど
失効時　　　　証明書を無効として登録　　　証明書所有者、RA、CA

つまり、

わけではありません。

事前にRAが確認し、CAがその確認結果を証明書として署名しておきます。

利用者は、そのCAの署名を確認することで証明書を信頼します。

なぜCAを信頼できるのか

ここで、次の疑問が出てきます。

ブラウザやOSには、あらかじめ信頼するCAの証明書が登録されています。

この証明書は、一般にルート証明書と呼ばれます。

ブラウザやOSは、このルート証明書を信頼の出発点とします。

証明書チェーン

Webサイトの証明書は、必ずしもルートCAが直接発行するとは限りません。

実際には、次のような階層構造になっていることがあります。

ルートCA
   │
   ▼
中間CA
   │
   ▼
Webサイトの証明書

ブラウザは、Webサイトの証明書から中間CA、ルートCAまで、電子署名を順番に確認します。

このつながりを、証明書チェーンまたは信頼の連鎖と呼びます。

最終的に、ブラウザやOSが信頼しているルートCAまでたどり着ければ、その証明書を信頼できます。

証明書の失効とは

電子証明書には有効期限があります。

しかし、有効期限内であっても、証明書を使わせてはいけない状態になることがあります。

たとえば、

• 秘密鍵が漏えいした

• 証明書の内容に誤りがあった

• 退職などで利用資格を失った

• ドメインやサーバの管理者が変わった

• 証明書が不正に取得された

といった場合です。

このようなとき、CAは証明書を失効させます。

失効とは、

と宣言することです。

CRL

CRLは、Certificate Revocation Listの略で、失効した証明書の一覧です。

ブラウザやシステムはCRLを確認することで、証明書が失効していないかを判断できます。

OCSP

OCSPは、Online Certificate Status Protocolの略です。

確認したい証明書について、

とオンラインで問い合わせる仕組みです。

CRLが失効証明書の一覧を取得する方式なのに対し、OCSPは特定の証明書の状態を問い合わせる方式です。

よくある勘違い

RAが証明書を発行する？

基本的な役割分担では、RAは本人確認・審査を行い、CAが証明書を発行します。

ただし、実際には同じ事業者やシステムの中で両方の機能が運用されていることがあります。

試験問題では、役割として区別して覚えるのが大切です。

証明書の中に秘密鍵が入っている？

電子証明書に入っているのは公開鍵です。

秘密鍵は証明書の所有者が自分で保管します。

秘密鍵をCAや通信相手へ渡してはいけません。

CAが通信内容を暗号化してくれる？

CAの主な役割は、公開鍵と所有者の関係を証明することです。

Webサイトとの実際の通信を行うのは、ブラウザとWebサーバです。

CAがすべての通信を中継したり、通信内容を暗号化したりするわけではありません。

証明書があれば、そのサイトは絶対に安全？

証明書が証明するのは、主に、

• 接続先の確認

• 公開鍵の正当性

• 通信の暗号化

です。

そのWebサイトが善良であることや、掲載されている商品・情報が正しいことまで保証するものではありません。

HTTPSであっても、フィッシングサイトや詐欺サイトの可能性はあります。

RAは証明書を使うたびに登場する？

基本的には登場しません。

RAが主に関わるのは、証明書の申請・本人確認・登録・失効申請などです。

証明書を実際に使うときは、利用者側のブラウザやシステムが、CAの署名、有効期限、失効状態などを検証します。

全体を一つの流れで整理する

最後に、電子証明書の一生をまとめます。

1. 鍵を作る
   公開鍵と秘密鍵のペアを作成する

2. 申請する
   公開鍵や申請情報をRAへ提出する

3. 本人確認する
   RAが申請者や申請内容を審査する

4. 発行する
   CAが証明書を作り、CAの秘密鍵で署名する

5. 利用する
   サーバなどが証明書を相手へ提示する

6. 検証する
   ブラウザなどがCAの署名や有効期限を確認する

7. 必要に応じて失効する
   秘密鍵漏えいなどがあれば証明書を無効にする

8. 有効期限を迎える
   必要であれば新しい証明書へ更新する

まとめ

PKIは、公開鍵と電子証明書を安全に利用するための仕組み全体です。

その中で、

• RAは、申請者の本人確認や審査をする

• CAは、証明書を発行し、電子署名を付ける

• 利用者は、CAの署名を検証して証明書を信頼する

という役割があります。

特に大切なのは、次の二つを分けて考えることです。

証明書を作ってもらうとき

申請者 → RAが確認 → CAが発行

証明書を使うとき

証明書を提示 → 相手がCAの署名などを検証

RAやCAが毎回の通信に参加するのではありません。

事前にRAが本人確認を行い、CAがその結果を電子証明書として署名します。

そして利用時には、ブラウザやシステムがその署名を検証します。

このように、

という三つの段階に分けると、PKIの仕組みが整理しやすくなります。