証明書には有効期限がありますが、期限より前に無効にしたい場面があります。秘密鍵が漏れた、担当者が退職した、機器を廃棄した。証明書自体は書き換えられないので、「取り消した」という情報を別に配る必要がある——これが失効確認の出発点です。
先に押さえる
検証側がやることは3つです。信頼する発行元から出ているか（署名の検証）、期限内か、そして失効していないか。最初の2つは証明書だけで確かめられますが、3つ目は外部に問い合わせないと分かりません。ここが抜けやすく、そのまま設問になります。
配り方は2通り
一覧をまとめて配る
- 失効した証明書の番号の一覧を定期的に発行する
- 検証側は取得して手元で照合する
- 利点：問い合わせが要らない。取得済みなら速い
- 欠点：次の発行までの時間差がある。件数が増えると大きくなる
その都度問い合わせる
- 1件ずつ「これは有効か」を尋ねる
- 利点：時間差が小さい。手元に一覧を持たなくてよい
- 欠点：問い合わせ先が落ちると確認できない。通信が増える
つまずきポイント
問い合わせ先に届かなかったときにどうするかが実は最大の論点です。「確認できないなら通す」設計だと、攻撃者は問い合わせを妨害するだけで失効証明書を通せます。逆に「確認できないなら止める」と、問い合わせ先の障害でサービス全体が止まります。設問はこの可用性と安全性の綱引きを必ず突いてきます。
動きで見る
13段構えで確かめる
受け取った証明書署名を信頼する発行元の鍵で検証する
↓通ったら次へ
有効期限今が期間内か（端末の時計が狂っていると誤判定する）
↓ここまでは証明書だけで分かる
失効の確認一覧を照合する／その都度問い合わせる外部との通信が要る
見抜きどころ
答案の芯は「期限内でも無効なことがあるから、失効を別に確かめる」です。方式を選ばせる設問では、時間差を許容できるかと問い合わせ先の可用性を根拠にします。時間差が許されない場面（決済・重要な社外連携）はその都度問い合わせ、通信を増やせない機器では一覧の配布、という整理になります。
失効させる側の手順
鍵が漏れたと分かったら、速やかに失効を申請し、新しい証明書に入れ替えるのが対応です。ここで問われるのは順番で、失効させただけでは通信は続きませんし、入れ替えただけでは古い証明書が生きたままです。両方をやり、失効が検証側に届くまでの時間も見込んで動きます。