¶ 🚫 証明書の失効（CRL / OCSP）
¶ 🧭 このページについて
証明書は「期限が切れたら使えない」というイメージが強いが、実務で怖いのは 期限内でも突然使えなくなるパターンである。
その代表が 失効（Revocation） で、これは「この証明書はもう信頼してはいけない」という判断を、期限とは別に配布する仕組みになる。
このページでは、失効が必要になる理由と、失効情報を配る仕組みである CRL と OCSP、そして運用（特にADCSで詰まりやすいポイント）を図中心で整理する。
¶ 📋 目次
- 失効とは（期限切れとの違い）
- なぜ失効が必要か（どんなときに起きるか）
- CRLとは（失効リスト）
- OCSPとは（オンライン照会）
- OCSPステープリングとは（サーバが代わりに提示）
- ブラウザはどう確認しているか（ざっくり）
- ADCS運用で重要な点（CRLの公開と期限）
- よくあるトラブル（症状→原因）
- 確認コマンド（最小セット）
- まとめ
¶ ✅ 失効とは（期限切れとの違い）
- 期限切れ（Expiration）：時間が来たので無効になる（予定どおり）
- 失効（Revocation）：期限前でも無効にする（緊急・例外）
証明書は「期限までの有効さ」だけでは足りず、途中で危険が分かったら止める必要がある。そこで失効の仕組みがある。
¶ 🧠 身近な例
- 期限切れ：免許証の更新忘れで無効になる
- 失効：免許停止のように、期限が残っていても使えなくなる
¶ ❓ なぜ失効が必要か（どんなときに起きるか）
失効の典型はだいたい次。
- 秘密鍵が漏れた可能性がある（なりすましが成立する）
- 誤って発行された（対象名の誤り、手続きミスなど）
- 利用者が退職した／端末を紛失した（クライアント証明書で多い）
- 用途が変わった／サービスを廃止した（もう使わせたくない）
ここで重要なのは、失効は「証明書を作り直す」だけでは済まないことがある点。
第三者が古い証明書を握っていたら、期限内は悪用できてしまう。だから「古い証明書は無効」と周知する仕組みが必要になる。
¶ 📄 CRLとは（失効リスト）
CRL（Certificate Revocation List）は、CAが公開する「失効した証明書の一覧」。
クライアント（ブラウザ等）は、証明書の中に書かれている CRL配布先（CDP） を見てCRLを取得し、対象証明書がリストに載っていないかを確認する。
¶ 🧠 身近な例
- CRL：無効になった身分証の一覧表
¶ 図：CRLの流れ（ざっくり）
¶ CRLの特徴（運用で効くポイント）
- 一覧なので サイズが大きくなりやすい
- ただし取得したCRLは キャッシュ されることが多い
- CAはCRLを 定期更新 するため、配布先が落ちると影響が大きい
¶ 🧾 OCSPとは（オンライン照会）
OCSP（Online Certificate Status Protocol）は、証明書の状態を 1枚単位で問い合わせる仕組み。
クライアントは、証明書の中に書かれている OCSPレスポンダURL に対して照会し、「Good / Revoked / Unknown」のような応答を受け取る。
¶ 🧠 身近な例
- OCSP：窓口に「この身分証はいま有効ですか」と問い合わせる
¶ 図：OCSPの流れ（ざっくり）
¶ OCSPの特徴（運用で効くポイント）
- 1枚単位なので、CRLより 通信が軽い方向になりやすい
- ただしオンライン照会なので、レスポンダ障害や通信遮断の影響を受ける
- クライアントの実装によっては「照会できない場合の扱い」が変わる
¶ 📎 OCSPステープリングとは（サーバが代わりに提示）
OCSPステープリング（OCSP Stapling）は、サーバがあらかじめOCSP応答を取得しておき、TLSハンドシェイク時にクライアントへ一緒に渡す方式。
クライアントが毎回OCSPレスポンダへ問い合わせなくてよくなり、速度とプライバシー面でメリットが出やすい。
¶ 🧠 身近な例
- 窓口に問い合わせる代わりに、サーバが「有効証明書（当日印）」を持ってくる
¶ 図：OCSPステープリング（流れ）
¶ 🔍 ブラウザはどう確認しているか（ざっくり）
ブラウザやOSの実装は細部が違うが、整理すると次の観点になる。
- 証明書が期限内か（Not Before / Not After）
- 信頼チェーンが成立しているか（ルートまで辿れるか）
- 失効していないか（CRL / OCSP）
¶ 🧠 身近な例
- 期限：期限切れの身分証ではないか
- チェーン：発行元が本物か（辿れるか）
- 失効：取り消されていないか
※ 実際のブラウザは、ネットワーク条件や速度の都合で「必ず毎回オンラインで確認する」とは限らない。だからこそ、運用側は「CRL/OCSPが落ちても良い」ではなく、落ちない設計を前提にした方が事故が少ない。
¶ 🏢 ADCS運用で重要な点（CRLの公開と期限）
ADCS（社内CA）では、失効は「できれば使わない」ではなく、運用上の前提になる。
特にクライアント証明書（VPN、無線、端末認証など）を使う場合、失効が効かないと「退職者の証明書がずっと使える」状態になりやすい。
ここで重要なのは次。
- CRL配布先（CDP）を必ず到達できる場所に置く
- CRLの更新間隔と有効期限（Next Update）を破綻させない
- 必要なら OCSPレスポンダ を用意する
- 失効情報が取れないと認証に影響する場面がある（製品・機能による）
¶ 図：ADCSの失効情報の置き場所（イメージ）
¶ 🧠 身近な例
- 失効が機能しない：退職者の社員証を止められない
- CRLが切れる：社員証の照会先が停止して、入口が混乱する
¶ 🚨 よくあるトラブル（症状→原因）
¶ 1) 「Revoked（失効しています）」
- 原因：本当に失効している（鍵漏えい、端末紛失、誤発行など）
- 対応：新しい証明書を発行し、古いものは撤去する（サーバ証明書なら差し替え）
¶ 2) 「CRLが取得できない」「CRLが期限切れ」
- 原因：CDP（CRL配布先）へ到達できない（ネットワーク、名前解決、公開先停止）
- 原因：CAがCRLを更新していない、公開が止まった
- 対応：CRL配布先の可用性と、CA側の公開スケジュールを確認する
¶ 3) 「OCSP応答が取れない」
- 原因：OCSPレスポンダへの到達性（FW、DNS）
- 原因：レスポンダ障害、疎通が遅い
- 対応：ステープリングの活用、レスポンダの冗長化（必要なら）
¶ 4) 「社内ではOK、社外ではNG」
- 原因：内部CAのルートが端末に入っていない（仕様）
- 対応：外部は公開CA、内部は内部CA、と用途で分ける
¶ 🧪 確認コマンド（最小セット）
¶ 1) 証明書の失効情報の参照先を見る（CDP / OCSP URL）
openssl x509 -in server.crt -noout -text
見るポイント（出力内）
- CRL Distribution Points（CDP）
- Authority Information Access（OCSP）
¶ 2) OCSP URL だけ抜き出す（ある場合）
openssl x509 -in server.crt -noout -ocsp_uri
¶ 3) OCSP照会（テスト）
openssl ocsp -issuer issuer.crt -cert server.crt -url http://ocsp.example/ -CAfile chain.crt
¶ 4) CRLを使って検証（ローカル検証）
openssl verify -crl_check -CAfile chain.crt -CRLfile ca.crl server.crt
¶ 5) （Windows）証明書のURL取得と検証（例）
certutil -url server.cer
certutil -verify server.cer
※ 実際のファイル形式やチェーン構成は環境に合わせる。ここでは「何を見ればよいか」を優先している。
¶ 🧾 まとめ
- 失効は「期限前に無効化する」仕組みで、鍵漏えいなどの事故時に必要になる
- CRLは失効一覧、OCSPは1枚単位のオンライン照会
- OCSPステープリングは、サーバがOCSP応答をまとめて提示する方式
- ADCSでは、CRLの公開先と更新が止まると影響が出やすいので、可用性と期限設計が重要になる
- まずは証明書に書かれている CDP / OCSP を確認して、参照先に到達できるかを事実で掴む