NTTドコモR&Dの技術ブログです。

トップ > セキュリティ > サーバ間におけるサーバ証明書失効情報確認の推奨実装

サーバ間におけるサーバ証明書失効情報確認の推奨実装

セキュリティ アドベントカレンダー2024

1. はじめに

NTTドコモ 第一プロダクトデザイン部の橋爪です。 「ユーザ体験価値向上」のため、「サービスの品質向上」「障害の早期復旧」「障害事例や優良事例のノウハウ化」に取り組んでいます。 本記事では、「ユーザ体験価値向上」のためのサーバ証明書の失効情報確認の実装について、お伝えできればと思います。

弊社が管理しているサーバから他社が管理しているサーバに対し暗号化通信を確立する際、暗号化通信を開始する前に、他社サーバのサーバ証明書の失効情報を確認しています。 あるシステムでは、OCSPのみで失効情報を確認していました。 そして、この失効情報確認において、弊社と契約関係にない中間証明書のOCSPレスポンダがダウンしたことにより、正常に失効情報を確認できませんでした。 その結果、契約関係にある通信先サーバと通信を確立できず障害が発生しました。 この時、契約関係にある通信先サーバは正常に稼動していたにもかかわらず、契約関係にないOCSPレスポンダのダウンにより障害が発生した、ということを運用課題と認識しました。

失効情報確認の実装によっては、このような障害を防げた可能性があります。 そこで、運用課題の解決と同じような障害の再発を防止するために、サーバ間におけるサーバ証明書の失効情報確認の適切な実装について整理しました。

図1.推奨実装の整理範囲

2. サーバ証明書の失効とは

サーバ証明書の失効とは、認証局がサーバ証明書を無効化することを意味します。 認証局は、以下のようなケースでサーバ証明書を無効化します。 - サーバ証明書の所有者が失効を要求した - サーバ証明書の秘密鍵が漏洩した - サーバ証明書の記載と事実が異なっていた

有効期間内でもサーバ証明書を無効にすることがある1ため、失効情報を適時確認する必要があります。

3. 失効情報確認の重要性

サーバ証明書が失効すると、以下のようなセキュリティリスクが発生する可能性があります。

  • ユーザの信頼性低下
    サーバ証明書が失効していると、ブラウザやセキュリティツールが警告を表示するため、ユーザの信頼を失います。
  • データの盗聴や改ざん
    通信内容を暗号化する鍵が破られている場合、この脆弱性を悪用し、通信内容を盗聴されたり、改ざんされたりする可能性があります。
  • 社会的信用の失墜
    PCI DSS（クレジットカード業界のセキュリティ基準）は、サーバ証明書の有効性を維持することを求めています。 これを守らないと、社会的信用の失墜や決済取引の減少などの悪影響が発生する可能性があります。
  • 法律上の違反
    取引先との契約において、セキュリティ対策の一環として有効なサーバ証明書の使用を義務付けることがあります。 失効したサーバ証明書を使用すると、契約違反となり、法的な責任を問われる可能性があります。

これらの理由から、サーバ証明書の失効情報確認は非常に重要です。

4.サーバ証明書の失効情報を確認する仕組み

サーバ証明書の失効情報確認に用いられる主な仕組みは、以下の3つです。

4.1. CRL（Certificate Revocation List）

CRLは、失効したサーバ証明書の一覧を記載したリストです。 失効したすべてのサーバ証明書が記載されており、定期的に認証局が更新します。 通信元サーバは、通信先サーバから受け取ったサーバ証明書をCRLと照合することで、そのサーバ証明書が失効しているかどうかを確認します。

CRLによる失効情報確認
  1. 認証局によるCRLの更新
    認証局は、失効したサーバ証明書のシリアル番号などを含むCRLを定期的に更新します。
  2. 通信元サーバによるCRLの取得
    通信元サーバは、通信先サーバから受け取ったサーバ証明書に記載されているCRL配布ポイント（URL）を参照し、CRLをダウンロードします。
  3. 通信元サーバによる検証 通信元サーバは、ダウンロードしたCRLの中に、検証しているサーバ証明書と同じシリアル番号のサーバ証明書が記載されているか検証します。 記載されていた場合、そのサーバ証明書が失効していると判断します。

クライアントから通信元サーバに処理を要求して、クライアントに結果が返却されるまでのイメージは図の通りです。

図2.CRLによる失効情報確認イメージ

4.2. OCSP（Online Certificate Status Protocol）

OCSPは、特定のサーバ証明書が有効かどうかをリアルタイムに通信元サーバが問い合わせるプロトコルです。 CRLのように、失効したサーバ証明書の一覧をダウンロードして確認するのではなく、必要な時に必要なサーバ証明書だけをOCSPレスポンダと呼ばれる認証局のサーバに通信元サーバが問い合わせて、サーバ証明書が失効しているか確認します。

OCSPによる失効情報確認
  1. 通信元サーバからOCSPレスポンダに問い合わせ
    通信元サーバは、通信先サーバから受け取ったサーバ証明書のシリアル番号をOCSPレスポンダに送信します。
  2. OCSPレスポンダによる応答
    OCSPレスポンダは、問い合わせを受けたサーバ証明書の失効情報を確認し、その結果を通信元サーバに返します。
  3. 通信元サーバによる検証
    通信元サーバは、OCSPレスポンダの応答を検証し、サーバ証明書の有効性を確認します。

クライアントから通信元サーバに処理を要求して、クライアントに結果が返却されるまでのイメージは図の通りです。

図3.OCSPによる失効情報確認イメージ

4.3. OCSP Stapling

OCSP Staplingは、サーバ証明書の失効情報をOCSPレスポンダに通信先サーバが問い合わせます。 OCSPレスポンダの応答を通信先サーバがキャッシュとして保持し、サーバ証明書とともに通信元サーバに送付します。 通信元サーバは、通信先サーバとのTLS/SSLハンドシェイクの過程でサーバ証明書が失効しているか確認します。

OCSP Staplingによる失効情報確認
  1. 通信先サーバからOCSPレスポンダに問い合わせ
    通信先サーバは、通信元サーバから接続要求を受けると、OCSPレスポンダに問い合わせます。
  2. OCSPレスポンダによる応答
    OCSPレスポンダは、問い合わせを受けたサーバ証明書の失効情報を確認し、その結果を通信先サーバに返します。
  3. OCSPレスポンダの応答キャッシュ
    通信先サーバは、OCSPレスポンダの応答をキャッシュします。
  4. 通信先サーバによる応答
    通信先サーバは、サーバ証明書とキャッシュしたOCSPレスポンダの応答を一緒に通信元サーバに送信します。
  5. 通信元サーバによる検証
    通信元サーバは、通信先サーバから受け取ったOCSP応答を検証し、サーバ証明書の有効性を確認します。

クライアントから通信元サーバに処理を要求して、クライアントに結果が返却されるまでのイメージは図の通りです。

図4.OCSP Staplingによる失効情報確認イメージ

5. 失効情報を確認する各仕組みのメリットとデメリット

CRL、OCSP、OCSP Staplingの仕組みを通信元サーバが実装する場合、それぞれ以下のようなメリットとデメリットがあります。

5.1. CRLのメリット

  • 安定性
    CRLをダウンロード済みであれば、CRL配布ポイントと接続できなくても失効情報を確認できます。

5.2. CRLのデメリット

  • 負荷
    CRLをダウンロードする時、ネットワークトラフィックが増加します。 多くのサーバ証明書が発行されている場合、CRLのサイズが大きくなり、それに比例してネットワークの負荷も増加します。 また、CRLのダウンロード、解析、キャッシュにより、通信元サーバの処理負荷が増加します。 特に、低スペックのサーバでは、動作が遅くなる可能性があります。
  • リアルタイム性
    失効したサーバ証明書の情報が反映されるまでに時間がかかります。 この間に、失効したサーバ証明書が利用される可能性があります。

5.3. OCSPのメリット

  • 効率性
    必要なサーバ証明書の情報のみを問い合わせるため、効率よく失効情報を確認できます。
  • リアルタイム性
    都度、サーバ証明書の失効情報を確認するため、最新の失効情報を確認できます。

5.4. OCSPのデメリット

  • OCSPレスポンダ負荷
    通信元サーバから問い合わせが集中すると、OCSPレスポンダに負荷がかかり応答が遅れる可能性があります。
  • 単一障害点
    OCSPレスポンダと接続できない場合、サーバ証明書の有効性を確認できなくなります。
  • セキュリティ問題
    OCSPレスポンダの問い合わせ内容から、通信元サーバのIPアドレスなどが漏洩する可能性があります。
  • プライバシー問題
    OCSPレスポンダは、送信元サーバからの問い合わせをログとして保存することがあります。 このログに送信元サーバの情報とサーバ証明書の識別情報を組み合わせて保存している場合、認証局にアクセス履歴が知られる可能性があります。

5.5. OCSP Staplingのメリット

  • パフォーマンス
    • 通信元サーバ側の処理速度向上
      OCSP Staplingでは、通信先サーバがOCSPレスポンダに問い合わせて取得した情報を、サーバ証明書と一緒に通信元サーバに提供します。 これにより、通信元サーバはOCSPレスポンダに問い合わせる必要がなくなり、処理速度が向上します。
    • ネットワークトラフィックの削減
      通信元サーバがOCSPレスポンダに直接問い合わせる回数が減るため、ネットワークトラフィックが削減されます。
  • セキュリティ
    通信先サーバがOCSPレスポンダに問い合わせるため、通信元サーバの情報漏洩の可能性が低減しセキュリティを強化できます。

5.6. OCSP Staplingのデメリット

  • キャッシュされた情報の信頼性
    失効情報確認結果のキャッシュを適切に通信先サーバが管理していなければ、古い失効情報確認結果が使用される可能性があります。

6. 失効情報確認の推奨実装

上記より、パフォーマンスとセキュリティという点で、失効情報確認はOCSP Staplingを利用する実装を推奨します。 特に、1秒当たりのトランザクション数が数百に上るような大規模なシステムや、高負荷が予想されるシステムにおいては、メリットをより多く享受できると考えられます。 そして、システムを取り扱う運用員と保守員だけでなく、OCSPレスポンダを管理しているベンダやユーザなど、すべてのシステム関係者が、この恩恵を受けることができるでしょう。

6.1. OCSP Stapling実装時のポイント

OCSP Staplingは、パフォーマンスとセキュリティを向上させる有効な手段ですが、実装に際しては注意点があります。

  • 通信先サーバのOCSP Stapling対応
    すべてのサーバがOCSP Staplingに対応しているわけではありません。 OCSP Staplingを利用する場合、通信先サーバがOCSP Staplingに対応しているか、ご確認ください。 OCSP Staplingが未対応だった場合、OCSPとCRLを組み合わせた失効情報確認を行ってください。
  • 動作試験
    通信先サーバから想定通り失効情報確認結果が返ってくるか動作を確認してください。 また、結果が返ってこなかった時のことを想定し、実装してください。 たとえば、確認結果を通信元サーバが一定期間キャッシュし、その情報をもとに処理を継続することは有効な対策手段となります。 キャッシュする場合には、情報が古くならないように適切な期間を設定するよう注意してください。

7. 失効情報確認結果に対するサーバ間通信可否の判断

OCSPとOCSP Staplingによる失効情報確認結果に応じた通信可否判断についても整理します。 サーバ証明書の失効情報確認結果として、以下のいずれかを通信元サーバが受け取ります。

  • 有効(good)
    サーバ証明書が失効していない状態
  • 失効(revoke)
    サーバ証明書が失効している状態
  • 不明(unknown)
    サーバ証明書が失効しているか、失効していないか判断できない状態

失効情報確認結果が「有効」の場合には、サーバ間の通信を許可します。 「失効」の場合には、サーバ間の通信を拒否します。 失効情報確認結果が「不明」だった場合には、以下の対応を検討します。

  • CRLで失効情報を確認する
  • 通信先サーバとの関係と通信要件によって通信可否を判断する

CRLの失効情報確認フローについては、上述の通りです。 通信先サーバとの関係性と通信要件による通信可否判断については、以下のように考えます。

  • 通信先サーバは、次の条件のいずれかに当てはまる特定のサーバか
    • IPアドレスが固定である
    • 専用線やVPN経由で通信する
    • 通信先サーバまでの通信経路が信用できる
  • 通信要件は、機密性低もしくは可用性重視か

これらの組み合わせによって、失効情報確認結果を受け取った後の通信可否を以下のように判断します。

図5.失効情報確認結果による通信可否判断フロー

8. まとめ

近年、サーバ証明書の有効期間が徐々に短くなってきています。

  • 2015年：有効期間が5年から3年に短縮
  • 2018年：有効期間が3年から2年に短縮
  • 2020年：有効期間が2年から1å¹´1ヶ月に短縮

Google社は、Webブラウザベンダーと認証局が参加する会議体「CA/Browser Forum」で有効期間を最大90日に短縮する方針と発表しています。2 また、Apple社は、2027年4月までに有効期間を45日までに短縮することを提唱しています。3

そして、サーバ証明書の発行数が世界最多の認証局であるLet's Encryptは、OCSPのサービスを終了する方針であると発表しました。4 OCSPのサービスを打ち切った場合、OCSPとOCSP Staplingが使えないため、Let's Encryptのサーバ証明書の失効確認は、CRLを利用することになります。 これは、サーバ証明書の有効期間が短い場合、OCSPよりもCRLの方が失効情報確認に有効であると、Let's Encryptが考えているからです。

一方で、エンタープライズ用途として、OCSP Staplingは、システムのセキュリティとパフォーマンスを向上させる有効な手段になります。 市場の動向、システム構成を考慮し、実装のポイントを踏まえながら、OCSP Staplingを実装していただければと思います。

本記事では、サーバ証明書の失効情報確認の重要性と推奨実装について解説しました。 最後まで読んでいただき、ありがとうございました。

参考文献

  1. デジサートのサーバー証明書に「O」を「o」とした誤記、5月12日に強制失効へ↩
  2. GoogleのSSLサーバ証明書、有効期間90日化について↩
  3. SSLサーバ証明書を90日から45日へ短縮する起案と、証明書自動化の役割↩
  4. Intent to End OCSP Service↩