CERT/CCは、暗号化通信に使うTLSライブラリの「名前制約」に関する13件の報告を、脆弱性情報VU#948176に整理しています。公表日は不明ですが、ベンダー情報の更新日は2026年10月14日です。修正済みと調査中の報告などが混在しており、名前制約に依存する会社は、利用ライブラリと証明書の扱いを確認する必要があります。
名前制約の検証差は、直ちに攻撃成立を意味しない
名前制約は、証明書を発行する下位の認証局(CA)が扱える名前を、許可された範囲に限定する仕組みです。CERT/CCによると、同じ制約対象の名前でも、ライブラリによって検証結果が異なります。構成によっては、意図した名前の範囲外にある名前を受け入れる恐れがあります。
ただし、検証結果の不一致だけで攻撃が成立するわけではありません。攻撃には、攻撃者が選んだ証明書項目に対して、信頼された署名を取得することが必要です。さらに、問題のある検証経路が使われ、受け入れた識別情報に基づいてアクセスを許可することも条件になります。
そのため、「TLSを使っている」という理由だけで、すべてのシステムを同じ緊急度で扱うのは適切ではありません。名前制約をどこで検証し、その結果を何のアクセス許可に使っているかが、影響を絞り込むポイントです。
修正済みと調査中を分けて確認
CERT/CCによると、GnuTLSのCVE-2026-3833は3.8.13、pyca/cryptographyのCVE-2026-34073は46.0.6、wolfSSLのCVE-2026-3547は5.9.0で修正されています。pyca/cryptographyでは、要求された接続先名に対する制約検証が欠けていました。
一方、Goのcrypto/x509に関する2件や、AppleのSecurity.frameworkに関する3件は調査中です。Go側がIPv4とIPv4マップドIPv6の報告をセキュリティ問題と認めなかった例もあります。13件を一律に「修正待ちの脆弱性」と扱うことはできません。
OpenSSLでは、URIのパスなどに含まれる@への対応としてPR #30319が統合されました。ただし、URIのユーザー情報内のコロンに関する別報告は調査中です。同じライブラリでも、報告ごとに状況を分ける必要があります。日本での提供は発表には書かれていません。
影響する会社・しない会社
- 影響する: 下位CAの名前制約を、証明書を信頼する範囲の限定に使っている会社です。CERT/CCは、この運用に依存する利用者に、実際のライブラリの挙動確認を勧めています。
- 影響する: 報告対象のライブラリを利用し、該当する検証経路で受け入れた識別情報をアクセス許可に使う会社です。導入の有無だけでなく、証明書から認可までの処理を確認する必要があります。
- 影響しない: と一律に断定できる会社の条件は、発表には書かれていません。個別の修正版を導入していても、ほかの報告への対応状況は別に確認してください。
情シスが今日やること
以下は社内の初動としての確認手順です。製品ごとの管理画面や操作箇所、対応期限は、発表には書かれていません。
- 今日の棚卸しで、システム台帳や依存関係の一覧から、利用するTLSライブラリと版を確認します。分からない製品は、開発担当や保守委託先に「ライブラリ名・版・名前制約の利用有無」を問い合わせます。
- 名前制約を使っているシステムは、証明書管理担当と開発担当に確認を依頼します。下位CAの制約、末端証明書の名前、受け入れた名前を使うアクセス許可の処理を、同じ経路で追ってください。
- 修正版が示された3件は、利用版と照合して更新の要否を整理します。調査中の報告とは分け、保守担当に更新計画と次回確認日を決めてもらいます。修正版の番号が示されていない報告を、自己判断で「最新版なら解消」と扱わないでください。
- 次の証明書発行や検証設定の変更前に、発行方針を見直します。CERT/CCは、末端証明書のSANという名前の記載欄に明示的な名前を使い、発行方針を第一の防御策とするよう勧めています。検証器を追加する場合も、同じ入力を使い、検証失敗時に拒否する構成かを確認します。
