OCSP staplingとは？
- 僭越ながら自身の記事: OCSP Staplingの調査
RFCへのリンク
-
OCSP
-
OCSP stapling
- RFC6066: Transport Layer Security (TLS) Extensions: Extension Definitions
- staplingという表現はなく、「11.6. Security Considerations for status_request」に記述あり。
- RFC6066: Transport Layer Security (TLS) Extensions: Extension Definitions
-
Multiple Certificate Status Request Extension
証明書検証の３方法の比較
- ChatGPTにより得られた比較表を添付する。
- OCSP Staplingの有効性は明らか。
| 項目 | CRL | OCSP | OCSP Stapling |
|---|---|---|---|
| 通信方式 | リストを定期ダウンロード | 1証明書ごとに問い合わせ | サーバーが事前取得し添付 |
| リアルタイム性 | ✖（最大で数日遅延あり） | ◯（リアルタイム） | ◯（ただしサーバー依存） |
| 通信の軽さ | ✖（CRLサイズが大きい） | ◯（1証明書あたりの通信） | ◎（追加通信なし） |
| プライバシー | ◯ | ✖（問い合わせ先が露呈） | ◎（クライアントからの外部通信なし） |
| クライアント依存性 | 高い | 高い | 低い（サーバー実装次第） |
| ブラウザ対応 | 古いが一部対応 | 多くのブラウザが対応 | モダンブラウザで対応 |
| 失効情報の信頼性 | △（取得タイミング次第） | ◯ | ◯（ただしStapleの有効期限に注意） |
| サーバーの負担 | なし（クライアント側） | なし | ◯（OCSPレスポンスの管理必要） |
なぜ Multiple OCSP staplingが必要か？
- 一般的なサーバ証明書は、以下に示すような３階層（以上）の証明連鎖構造をとっており、少なくとも、サーバ証明書、中間証明書は証明書自体の有効性をチェックする必要がある。
┌─────────────────────┐
│ ルート証明書 │
│ (Root Certificate) │
│ 信頼の出発点（自己署名）│
└────────┬────────────┘
│
▼
┌─────────────────────┐
│ 中間証明書 │
│ (Intermediate CA) │
│ ルートによって署名済 │
└────────┬────────────┘
│
▼
┌──────────────────────┐
│ サーバ証明書 │
│ (Server Certificate) │
│ 実際のサービス用 │
│ 中間CAによって署名 │
└──────────────────────┘
- OCSP staplingは一つの証明書に対するOCSPレスポンスしかstapleできない。複数の証明書を検証する場合、上記、比較結果はどうなるか？ 改めてChatGPCに整理してもらう。
| 比較項目 | CRL | OCSP | OCSP Stapling |
|---|---|---|---|
| サーバ証明書の検証 | ✅ 可能 （CRLリスト内を検索） |
✅ 可能 （証明書単位で問い合わせ） |
✅ 可能 （サーバーがOCSPレスポンスをStaple） |
| 中間証明書の検証 | ✅ 可能 （ただし手動DL・検証が必要、ブラウザ実装依存） |
◯ 一部実装で自動確認されるが すべての環境で保証されない |
❌ Staplingはサーバー証明書のOCSPレスポンスしか含められない |
| リアルタイム性 | ✖ 遅延あり（CRL更新周期に依存） | ◯ OCSPレスポンスは短期有効で比較的リアルタイム | ◯ Stapleも短期レスポンスだが 更新タイミングはサーバー依存 |
| 通信コスト | ✖ 高い （CRLファイルは大容量） |
◯ 少ない （失効状態だけ問い合わせ） |
◎ 通信負荷なし （クライアント→OCSPレスポンダー通信が不要） |
| プライバシー保護 | ◯ クライアントからの外部通信なし | ✖ クライアントがCAへ直接照会＝追跡可能 | ◎ クライアントから外部照会しない |
| 中間CA失効への対応 | △ クライアントがCRLで手動確認可能 | △ 確認できるが実装依存／失敗しても接続成功になるケース多い | ❌ 中間証明書の失効状態は含まれない |
| 現実的な運用 | △ 信頼性はあるが負荷と手間が大きい | ◯ 安定的だが外部通信や中間CA確認の不確実性あり | ◎ サーバー証明書の検証には最も合理的だが、中間CA検証は別途必要 |
- 中間証明書の検証に関して、OCSP staplingの欠点（未対応？）が顕著となる。ChatGPTの中間証明書を含む検証方法の推奨は以下のとおりだった。
- Must-Stapleとは、証明書に付加される拡張属性で、TLSハンドシェイク時にOCSP Staplingが必須であることをクライアントに通知するための仕組み
| 検証対象 | 推奨手段 |
|---|---|
| サーバ証明書 | OCSP Stapling + Must-Staple |
| 中間証明書 | CRL or OCSPを定期チェック＋自動更新（例：OSの証明書ストア） |
- RFC6962 「The Transport Layer Security (TLS) Multiple Certificate Status Request Extension」は、複数のOCSPレスポンスをstapleするもので、これにより、上記、課題は解決するのではないか？
Multiple OCSP staplingはまだ実装されていないのか？
-
これについてもChatGPTが回答してくれた。（果たして本記事を投稿する意味はあるのか？）
-
RFC6962に基づく仕組みで、中間証明書のOCSPレスポンスもStaplingできるのではないか？
➡ 理論上は Yes、現実には No（未標準・未普及）RFC 6962（Certificate Transparency、CT）には複数のOCSPレスポンスや証明書ステータスをStaplingするための拡張的仕組みが含まれています。 ですが、現時点（2025年現在）では、中間証明書のOCSPレスポンスをTLSハンドシェイクにStaplingして送信する正式な標準実装は存在していません。
RFC6962はMultiple OCSP staplingを表すものではない
-
RFC6962の整理
RFC 6962（2013年） タイトル: Certificate Transparency 目的：証明書の公開ログ（CTログ）により、不正な証明書の発行を検出・防止する仕組み。 主な構成要素： Signed Certificate Timestamps（SCTs） CTログサーバ クライアントによる検証 補足として、RFC6962 Section 3.3 では OCSP_RESPONSE や X509_CHAIN_ENTRY のような複数証明書の情報を保持できる構造（Merkle Tree Leafなど）が示唆されています。 -
RFC 6962はOCSP Staplingの拡張仕様ではない。
- 証明書の公開ログ（CTログ）に関する仕様であり、失効確認ではなく「発行の監視・可視化」が目的。
- OCSP Stapling（特に中間証明書対応）は別の仕様で、現時点では未標準・未対応。
まとめ（考察）
- OCSP staplingは、１つの証明書検証においては、他の検証方法（CRLや直接OCSP）より利点が多い。
- 一般のサーバ証明書は、３階層以上の証明書連鎖構造を持っており、少なくとも、サーバ証明書、中間証明書の２証明書の検証が必要。
- RFC6962は、タイトル「Multiple Certificate Status Request Extension」から、複数の証明書についてOCSP応答をstapleするための仕様と思っていたが、全く別物。
- 現状、中間証明書に関しては、OCSP staplingとは別に、CRL、または直接OCSPによる証明書検証が必要。