はじめに
最近、情報安全確保支援試験に向けて勉強していて、「証明書まわり」関連の知識を求められることがけっこうあるなー思います。
HTTPS、SSL/TLS、電子証明書、CA(認証局)、OCSP、CRL、鍵長、署名アルゴリズム……。
試験ではこれらって当たり前に出てくるのですが、「何となく」で理解を進めているといざ本番で失点する要素になるんですよね。
ただ、実務では暗号化や証明書はほぼ触れる機会がなく、馴染みがない。そのため、イメージがしづらく知識の定着がわるい!
そこでこの記事では、自分の知識定着もかねて、証明書関連の基本事項をまとめていきます。
1. 証明書関連知識
- 基本
- 公開鍵暗号方式
- 証明書の役割
- 認証局(CA)
- 構造
- 公開鍵
- 所有者情報
- 有効期限
- 発行者情報
- 署名
- 拡張キー使用法
- 種類
- DV証明書
- OV証明書
- EV証明書
- 検証
- CAチェーン
- 失効確認
- OCSP
- CRL
- OCSP Stapling
- 運用
- 発行
- 配布
- 更新
- 失効
- 試験ポイント
- 有効期限と失効の違い
- 自己署名証明書の扱い
- 中間CAの信頼性
2. 証明書の基礎知識
3.1 公開鍵暗号と証明書の役割
-
公開鍵暗号方式を使って「暗号化」「署名」「認証」を行う
-
証明書は「公開鍵が誰のものであるか」をCAが保証するためのもの
3.2 証明書の構造(主要フィールド)
-
公開鍵
-
所有者情報(CN, O, OU)
-
有効期限(Not Before / Not After)
-
発行者(Issuer)
-
署名アルゴリズム(例:SHA-256 with RSA)
-
Key Usage / Extended Key Usage
📌 ポイント
この構造がわかっていると、試験で「この証明書でメール暗号化は可能か?」といった問題に対応できる。
4. 証明書の検証プロセス(CAチェーン)
CAチェーンとは
- CAチェーンとは、サーバ証明書が信頼できるルート認証局(Root CA)までたどれることを証明する「つながり」 のこと
- ブラウザやOSは、あらかじめ信頼できるルートCA証明書を「信頼ストア」に持っている
- サーバ証明書は、直接そのルートCAが署名している場合もありますが、多くは中間CAが間に入り、そのつながりを確認していく必要がある
検証の流れ(ブラウザ視点)
-
ブラウザはサーバ証明書を受け取る
-
サーバ証明書の発行者(Issuer)を確認
-
その発行者が署名した中間CA証明書を探す(サーバから送られてくる場合も多い)
-
中間CA証明書の発行者をさらに確認し、ルートCAにたどり着くまで繰り返す
-
ルートCAが信頼ストアにあれば、「この証明書は信頼できる」と判断
5. 証明書検証の流れを可視化してみた
試験問題でもよく問われるのが、証明書の検証フローです。
文章で覚えるよりも、図で見るほうが頭に残るのでMermaidで描いてみました。
ポイント整理
-
証明書は「公開鍵の正当性」を保証するもの
ドメイン名や組織名、有効期限も含まれる。 -
検証の3本柱
-
署名検証(CAの秘密鍵で署名 → クライアントがCAの公開鍵で検証)
-
有効期限チェック
-
失効確認(OCSPまたはCRL)
-
-
実務ではOCSP Staplingなどパフォーマンス向上の仕組みもある。
用語チェック:OCSPとは?
OCSPとは?
OCSP(Online Certificate Status Protocol) は、証明書が有効か失効しているかをリアルタイムに確認するためのプロトコルです。特徴
-
クライアント(ブラウザなど)が 証明書のシリアル番号 を OCSPレスポンダ(OCSPサーバ)に送信
-
サーバは「有効」「失効」「不明」のステータスを返す
-
リアルタイム性が高い(最新の状態を確認可能)
-
通常はHTTPS通信前の証明書検証時に行われる
メリット
-
CRL(証明書失効リスト)と比べて、必要な証明書の状態だけを問い合わせるため通信量が少ない
-
失効情報の反映が早い(CAが更新すれば即反映される)
デメリット
-
OCSPサーバにアクセスできない場合、通信遅延や接続失敗の原因になることがある
-
プライバシーの懸念(どのサイトにアクセスしたかCAに知られる)
実務での改善策
- OCSP Stapling:Webサーバ側が事前にOCSPレスポンスを取得してクライアントに送信
→ クライアントは直接OCSPサーバにアクセスする必要がなくなる(高速&プライバシー保護)
用語チェック2:CRLとは?
CRLとは?
CRL(Certificate Revocation List) は、認証局(CA)が発行する 失効した証明書の一覧 です。特徴
-
「失効済み証明書のシリアル番号一覧」をまとめたファイル
-
定期的(例:1日1回など)に更新され、CAの公開サーバで配布
-
ブラウザやOSは、証明書検証時にこのリストを参照して失効状態を確認する
メリット
-
一度ダウンロードすればオフラインでも参照可能(イントラ環境や制限ネットワークでも利用可)
-
失効証明書のリスト全体を持っているため、複数サイトに対して効率的にチェック可能
デメリット
-
リストが大きくなりやすく、ダウンロードに時間がかかる
-
更新間隔があるため、最新の失効情報が反映されるまで遅延が発生(リアルタイム性が低い)
-
クライアントが古いCRLを参照してしまうと失効証明書を見逃す危険がある
OCSPとCRLの比較
項目 | OCSP(Online Certificate Status Protocol) | CRL(Certificate Revocation List) |
---|---|---|
方式 | 証明書の失効状態をリアルタイムに問い合わせ | 失効証明書の一覧ファイルを定期的にダウンロード |
処理単位 | 証明書ごとに状態を確認 | リスト全体を取得して照合 |
即時性 | 高い(問い合わせ時点の最新情報) | 低い(更新間隔次第で遅延あり) |
通信量 | 少ない(対象証明書の情報だけ送受信) | 多い(全失効リストを取得) |
オフライン利用 | 不可(オンライン接続必須) | 可能(事前取得したCRLを参照) |
実装例 | ブラウザやOSがCAのOCSPサーバへHTTPリクエスト | ブラウザやOSがCRL配布URLからファイル取得 |
欠点 | OCSPサーバ障害時に検証不可になる可能性 | リストが大きくなるとダウンロード負荷が高い |
💡 ざっくりまとめ
-
OCSP = 「今この証明書は有効?」を都度問い合わせる方式(リアルタイム)
-
CRL = 「失効証明書のリスト」を定期更新して持っておく方式(オフライン可)
6. 証明書の種類
-
DV(Domain Validation): ドメイン所有確認のみ
-
OV(Organization Validation): 組織情報も確認
-
EV(Extended Validation): 法的な組織存在の厳格確認
7. まとめ
-
SC試験では「証明書の構造」「検証方法」「失効確認」が鉄板
-
実務でもHTTPS・メールセキュリティ・VPNなどで必須
-
OCSPとCRLは比較で覚えると記憶に残る