情報セキュリティマネジメント 2018年 秋期 午前(科目A) 問22
問題文
A社のWebサーバは、サーバ証明書を使ってTLS通信を行っている。PCからA社のWebサーバへのTLSを用いたアクセスにおいて、当該PCがサーバ証明書を入手した後に、認証局の公開鍵を利用して行う動作はどれか。
選択肢
ア:暗号化通信に利用する共通鍵を、認証局の公開鍵を使って復号する。
イ:暗号化通信に利用する共通鍵を生成し、認証局の公開鍵を使って暗号化する。
ウ:サーバ証明書の正当性を、認証局の公開鍵を使って検証する。(正解)
エ:利用者が入力して送付する秘匿データを、認証局の公開鍵を使って暗号化する。
🔒 解説は解答すると表示されます
サーバ証明書の検証【情報セキュリティマネジメント解説】
正解の理由
サーバ証明書とは、サーバの公開鍵(公開鍵=誰でも使える暗号の鍵)やサーバ名、有効期間などを第三者(認証局:CA=Certificate Authority)が署名した電子文書です。認証局の公開鍵は、認証局がその証明書に付けた「電子署名」を検証するために使います。したがって、PCがサーバ証明書を入手した後に行う動作は、認証局の公開鍵を使ってその署名(=正当性)を検証することです。これが選択肢の ウ に該当します。
ポイント:
- 証明書は「この公開鍵はこのサーバに属します」という証明書類。
- 認証局は自分の秘密鍵で証明書に署名する。
- クライアントは認証局の公開鍵でその署名を検証し、改ざんやなりすましを検出する。
解法ステップ
- 用語を整理する(サーバ証明書、認証局、公開鍵、共通鍵の意味を確認)。
- 「認証局の公開鍵は何に使う?」を考える。公開鍵で「検証(署名の確認)」ができる。
- 選択肢を一つずつ当てはめる。署名の検証に該当するのが ウ で正しいと判断する。
(短く言えば:「署名を確認する=検証」→ ウ)
選択肢別の誤答解説
-
ア: 暗号化通信に利用する共通鍵を、認証局の公開鍵を使って復号する。
誤り。復号(データを元に戻す)には通常、対応する秘密鍵が必要です。さらに共通鍵(対称鍵)はクライアントとサーバの間で共有されるもので、認証局の公開鍵で「復号」する、という流れ自体が意味をなさない場面です。 -
イ: 暗号化通信に利用する共通鍵を生成し、認証局の公開鍵を使って暗号化する。
誤り。もし共通鍵を暗号化して送るなら、送る相手(サーバ)の受け取れるようにサーバの公開鍵で暗号化します。認証局は鍵配送のための中継先ではありません。認証局の公開鍵で暗号化すると、その暗号文は認証局しか(理論上は)復号できず、通信相手のサーバは復号できません。 -
ウ: サーバ証明書の正当性を、認証局の公開鍵を使って検証する。
正しい。認証局の秘密鍵で署名された証明書は、対応する公開鍵で署名検証が可能です。これにより証明書が改ざんされていないか、発行者が信頼できるかを確認します。 -
エ: 利用者が入力して送付する秘匿データを、認証局の公開鍵を使って暗号化する。
誤り。利用者のデータを守るには、通常はサーバとの間で確立した共通鍵(セッション鍵)で暗号化するか、サーバの公開鍵で暗号化します。認証局の公開鍵はデータの送受信のために使うものではなく、証明書の検証が主目的です。
よくある誤解
- 「認証局の公開鍵で通信の暗号化や復号もする」と考える誤解。実務では、CAの公開鍵は証明書(署名)の検証のために使うだけです。
- 「サーバの公開鍵と認証局の公開鍵を混同する」こと。サーバの公開鍵は通信相手を特定して暗号化に関与する場合がありますが、CAの公開鍵は署名の検証に使います。
- 「署名と暗号化は同じ」と考える誤解。署名は改ざん検出と発行者確認、暗号化は情報を隠すために使う別の目的です。
補足コラム
TLS(Transport Layer Security:通信の暗号化プロトコル)の簡単な流れ(要点のみ):
- サーバは証明書を送る。証明書にはサーバの公開鍵と認証局の署名が含まれる。
- クライアントは認証局の公開鍵(OSやブラウザが信頼するルートストアに入っている)で証明書の署名を検証する。さらに有効期限や目的(例:ウェブ用であるか)も確認する。
- 証明書が信頼できれば、クライアントとサーバは安全な共通鍵(セッション鍵)を作り、以後の通信はその共通鍵で速く暗号化する。現代のTLSでは、セッション鍵は主に「一時的な鍵交換(例:Diffie-Hellman)」で作られ、サーバの秘密鍵は署名検証の整合性確保に使われることが多いです。
現場での運用イメージ:
- 社内PCではOSやブラウザの「信頼されたルート認証局」リストを管理します。不要なルートCAを残すとリスクになります。
- サーバ証明書が期限切れ、あるいは名前と合わないと、ブラウザは警告を出すため速やかに再発行・更新を行います。
- 証明書失効確認(CRLやOCSP)も運用でチェックされます。
FAQ
Q1: 認証局の公開鍵はどこにあるのですか?
A1: 普通はOSやブラウザがあらかじめ持っている「信頼されたルート証明書(公開鍵を含む)」に入っています。企業ではこれを管理して不要なCAを削除したり、社内CAを追加したりします。
A1: 普通はOSやブラウザがあらかじめ持っている「信頼されたルート証明書(公開鍵を含む)」に入っています。企業ではこれを管理して不要なCAを削除したり、社内CAを追加したりします。
Q2: サーバ証明書が自己署名(自前で署名)だったら?
A2: 自己署名証明書は認証局の署名がないため、クライアントは自動的には信頼しません。社内環境ではクライアント側にその自己署名証明書(ルート)を信頼させる設定が必要です。
A2: 自己署名証明書は認証局の署名がないため、クライアントは自動的には信頼しません。社内環境ではクライアント側にその自己署名証明書(ルート)を信頼させる設定が必要です。
Q3: 証明書の検証に失敗したらどうなる?
A3: ブラウザやクライアントは警告を出します。業務システムなら接続を拒否したり、例外手順を取ることになります。原因としては期限切れ、名前不一致、失効、未信頼のCAなどが考えられます。
A3: ブラウザやクライアントは警告を出します。業務システムなら接続を拒否したり、例外手順を取ることになります。原因としては期限切れ、名前不一致、失効、未信頼のCAなどが考えられます。
関連キーワード: TLS、サーバ証明書、認証局(CA)、公開鍵暗号、共通鍵(対称鍵)、デジタル署名、証明書チェーン、CRL、OCSP、ハンドシェイク

\ せっかくなら /
情報セキュリティマネジメントを
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

