証明書失効：CRL・OCSP・OCSP ステープリング

なぜ「期限切れ」だけでは足りないのか

証明書には有効期限があります。では期限内なら常に信じてよいかというと、そうはいきません。サーバーの秘密鍵が漏えいした、誤って発行した、ドメインの所有者が変わった——こうした場合、有効期限を待たずにいま証明書を無効化したい。これが失効（revocation）です。TLS のハンドシェイクでサーバー証明書のチェーンと署名を検証しても、それは「正しく発行された本物か」を確かめるだけで、「その後に取り消されていないか」までは分かりません。失効確認はチェーン検証とは独立した、もう一段のチェックです。

失効情報を出せるのは証明書を発行した CA（認証局） だけで、配布されるデータには必ず CA の署名が付きます。署名がなければ、攻撃者が「あの証明書は失効した／していない」を自由に偽れてしまうからです。失効の真正性は、結局この CA 署名に帰着します。

CRL：失効した証明書の一覧を配る

最初の方式が CRL（Certificate Revocation List、RFC 5280） です。CA が「失効させた証明書のシリアル番号の一覧」に署名し、定期的に公開します。証明書の中の CRL Distribution Points 拡張に一覧の配布 URL が書かれており、検証側はそれを取得して、確認したいシリアル番号が載っているかを照合します。

CRL（CAが署名する失効一覧）:
  thisUpdate: 2026-06-24 00:00:00   # この一覧の発行時刻
  nextUpdate: 2026-07-01 00:00:00   # 次回更新の予定（それまで再利用可）
  失効エントリ:
    serial=0x1A2B  revocationDate=...  reason=keyCompromise
    serial=0x3C4D  revocationDate=...  reason=cessationOfOperation
    ...（CAが今までに失効させた全件）
  signature: <CA秘密鍵による署名>

CRL の難点は 肥大化 です。一覧には CA がこれまでに失効させた証明書が（まだ有効期限内のものは）すべて載るため、大手 CA では数 MB に達することがあります。TLS 接続のたびにこれを丸ごと取得するのは非現実的なので、実際にはキャッシュして nextUpdate まで使い回します。ところがそれは、直近に失効した証明書がキャッシュ期限が切れるまで「まだ有効」と見えてしまう ことを意味します。鮮度（最新性）と転送量がトレードオフになるのが CRL の構造的な弱点です。

OCSP：1件だけを問い合わせる

肥大化を避ける発想が OCSP（Online Certificate Status Protocol、RFC 6960） です。一覧を丸ごと取る代わりに、「このシリアル番号の証明書は今どういう状態か」を 1件だけ CA（が運用する OCSP レスポンダ）に問い合わせます。応答は good・revoked・unknown のいずれかで、これにも CA（またはその委任を受けた応答者）の署名が付きます。

OCSPリクエスト  -> レスポンダ:
  対象証明書のシリアル番号 + 発行者の名前・鍵のハッシュ

OCSPレスポンス  <- レスポンダ:
  certStatus: good | revoked | unknown
  thisUpdate / nextUpdate          # 応答の鮮度
  signature: <レスポンダの署名>

転送量は CRL より格段に小さくなりますが、OCSP は別の問題を二つ抱えます。

第一に プライバシー です。クライアントが OCSP を引くと、「いつ・どのサイトの証明書を確認したか」が CA に筒抜けになります。ユーザーの閲覧先が第三者である CA に漏れる構造で、TLS が守ろうとした秘匿性に穴をあけかねません。

第二に 可用性 です。レスポンダへの問い合わせが TLS ハンドシェイクの途中に挟まると、レスポンダが遅い・落ちていると接続全体が止まります。これを避けるため、多くのクライアントは「応答が得られなければ通す」ソフトフェイル を採用しました。ところがソフトフェイルだと、攻撃者が OCSP 通信を遮断するだけで失効確認を無効化でき、失効した証明書を使い続けられてしまいます。厳格に「応答が無ければ拒否（ハードフェイル）」にすると、今度はレスポンダ障害で正規サイトに繋がらなくなる。この板挟みが OCSP の根本的なジレンマです。

OCSP ステープリング：問い合わせをサーバーに肩代わりさせる

プライバシーと可用性の両方を一手で改善するのが OCSP ステープリング（RFC 6066 の status_request 拡張）です。発想の転換は単純で、クライアントではなくサーバーがあらかじめ OCSP 応答を取得しておき、TLS ハンドシェイクの中でサーバー証明書に「ホチキス留め（staple）」して一緒に渡す、というものです。

1. サーバーが定期的に自分の証明書のOCSP応答をレスポンダから取得・キャッシュ
2. クライアントが ClientHello で status_request 拡張を提示
3. サーバーが署名済みOCSP応答をハンドシェイク内に同梱して返す
4. クライアントはCAへ問い合わせず、同梱された応答の署名と鮮度を検証

これでクライアントは CA に一切問い合わせないため、閲覧先が CA に漏れない（プライバシー改善）。問い合わせ回数も「全クライアント × 接続数」から「サーバーが定期取得する分」へと激減します（可用性・負荷改善）。応答には CA の署名と thisUpdate/nextUpdate が入っているので、サーバーが古い応答や偽の応答を差し込むことはできません。サーバーは仲介して運ぶだけで、信頼の根は依然 CA の署名にあります。

Must-Staple：ソフトフェイルの穴を構造的に塞ぐ

ステープリングだけでは、まだ抜け道が残ります。攻撃者がステープルされた応答を剥がして渡せば、クライアントは「応答が無い」と見なし、ソフトフェイルでそのまま通してしまう。これを塞ぐのが OCSP Must-Staple（TLS Feature 拡張、RFC 7633）です。

Must-Staple は 証明書そのものに刻印 する宣言で、「この証明書を使うなら、ハンドシェイクに必ず有効な OCSP 応答をステープルせよ」という意味を持ちます。刻印は CA が証明書発行時に署名込みで埋め込むため、攻撃者が後から消すことはできません。クライアントは Must-Staple 付きの証明書を受け取ったら、ステープルが無いハンドシェイクをハードフェイルとして拒否します。

これで、可用性を壊さずにハードフェイル相当の厳格さが得られます。レスポンダ障害の影響を受けるのはそのサーバーだけで（自分でOCSP応答を取得・キャッシュできなければ自分が繋がらないだけ）、CA レスポンダの一時障害が全インターネットを巻き込む事態は避けられるからです。応答の取得責任がクライアント群からサーバー1台に移ることが、ハードフェイルを現実的にしています。

三方式の比較

一段で言うと

証明書失効は「漏えい・誤発行した証明書を期限前に無効化する」仕組みで、土台は CA 署名付きの失効情報です。一覧を配る CRL は肥大化し、1件を引く OCSP はプライバシーとソフトフェイルの矛盾を抱える。そこで OCSP ステープリングがサーバーに署名済み応答を肩代わりさせてクライアントの問い合わせを消し、Must-Staple が「応答無しは拒否」を証明書に刻んで ソフトフェイルの穴を塞ぎます。挙動の裏取りには openssl s_client -connect host:443 -status（ステープルされた OCSP 応答の有無と certStatus を確認）と、証明書の tls-feature 拡張に Must-Staple が立っているかの確認を使ってください。HTTPS の信頼を支える最後の一段が、この失効確認です（HTTP の基礎 も併読を）。