概要
アプリケーションが1つのWOLFSSL_CTXまたは証明書マネージャ上でOCSPおよびCRLの失効確認の両方を有効にした場合、wolfSSLはAuthority Information AccessのOCSP URLを持たないピア証明書に対してCRLチェックをスキップし、ロードされたCRLに失効済みと記載されている証明書をそのまま受け入れてしまいます。レスポンダーが存在しない場合のソフトフェイルポリシーは、CRLフォールバックがまだ必要かどうかをコードが判断する前にOCSP結果を成功として扱うため、「レスポンダーが存在しない」と「レスポンダーが正常に応答した」の区別がつかなくなります。影響を受けるビルドは、HAVE_OCSPおよびHAVE_CRLの両方を定義しており、直接的には–enable-ocsp –enable-crl、そして暗黙的に–enable-all、–enable-distro、–enable-curl、–enable-nginx、–enable-haproxy、–enable-stunnel、–enable-lighty、–enable-wpas、–enable-strongswan、–enable-mosquitto、–enable-jni、–enable-openvpnおよび–enable-krbを含みます。アプリケーションが影響を受けるのは、wolfSSL_CTX_EnableOCSP()（またはwolfSSL_EnableOCSP() / wolfSSL_CertManagerEnableOCSP()）とwolfSSL_CTX_EnableCRL()（または同等の関数）を呼び出し、かつCRLがロードされている場合のみです。wolfSSL_CTX_EnableOCSPStapling()を通じてOCSPスタンプリングのみを使用するアプリケーションは影響を受けません。なぜなら、それが別のOCSPインスタンスを設定するためです。この欠陥はProcessPeerCerts()内にあり、TLS 1.0からTLS 1.3およびDTLSまでの間、クライアントがサーバ証明書を検証する場合およびサーバがクライアント証明書を検証する相互認証またはポストハンドシェイク認証の両方の場面で発生します。スキップされるチェックがリーフ証明書ではなくチェーン証明書に対して行われた場合、未検証の中間証明書が証明書マネージャに昇格され、そのコンテキストの後続の全ての接続において信頼された署名者として存続します。そのため、影響を受ける長時間稼働のプロセスではWOLFSSL_CTXの破棄が必要となり、ライブラリの入れ替えだけでは問題を解決できません。バージョン5.9.2以前の全てのwolfSSLが影響を受けます。特にバージョン5.9.1および5.9.2ではWOLFSSL_OCSP_CHECKALL設定はOCSP_NEED_URLで失敗となり、結果として5.9.2ではCHECKALLなしのwolfSSL_CTX_EnableOCSP()だけが公開された設定となっています。
技術情報
- 深刻度: 中
- 公開日: 2026-09-30T17:33:19+09:00
- 更新日: 2026-09-30T17:33:19+09:00
参考リンク
対処方法
該当ソフトウェアの最新版への更新、または開発元が提供する緩和策の適用を推奨します。運用環境に応じて事前検証の上で実施してください。
免責
本記事は公開情報をもとに自動集約された速報です。正確性・完全性は保証できません。必ず一次情報（上記リンク等）をご確認ください。
