Firefoxが不正な証明書への対策を追加！OneCRL配信が届かない端末も更新を確認

Mozillaは2026年10月20日、eMudhraの中間証明書に対応する秘密鍵の侵害を受け、Firefox利用者を保護する対策を公表しました。17日にOneCRLで対象証明書を遮断し、20日には通常の配信を受け取れない設定や環境を補うFirefoxの更新も提供しています。

本稿は10月20日に公式発表、勧告、技術文書を確認したものです。秘密鍵に関する報告を受けた日時と、更新を公表した日を区別します。既存のFirefox 158のメモリー安全性等の修正とは別の新しい対応です。以下の端末点検や接続確認は本サイトの提案で、実際の盗聴被害やAI悪用を確認したものではありません。

出典：Mozilla：eMudhraの中間証明書の問題を受けたFirefox利用者の保護

何が起きたとMozillaが説明しているか

Mozillaによると、10月17日20時06分UTCに、8つのeMudhra中間証明書に関係する秘密鍵が侵害されたという報告を受けました。この時刻は日本時間では18日5時06分です。同社はOneCRLで遮断し、17日22時59分UTCまでに標準設定のFirefoxへの更新配信を完了したと説明しています。

攻撃者がこうした鍵を使って偽のHTTPS証明書を発行し、さらに利用者の通信を横取りできる場合、サイトになりすまして通信を読んだり変更したりするおそれがあります。鍵の侵害だけで、あらゆる利用者の通信へ自動的に到達できるわけではありません。攻撃の成立に通信経路などの条件が関係します。

今回の発表は、この危険に対してブラウザー側が信頼を取り消す情報を配布したというものです。すべてのHTTPS暗号が破られた、特定サイトのパスワードが盗まれた、といった被害の結論を資料にないまま付け足さないでください。

出典：Mozilla：eMudhraの中間証明書の問題を受けたFirefox利用者の保護

証明書の署名が正しくても信頼を取り消す場合がある

一般的なHTTPSでは、接続先の証明書だけでなく、その証明書を発行した中間認証局、上位の信頼された認証局へ続く関係を確認します。署名や接続先名、有効期間などが検証対象になりますが、過去に信頼した鍵や証明書を、問題発生後も永久に信頼し続けるわけではありません。

失効や遮断の情報は、この信頼の変更を利用者側へ伝える役割を持ちます。証明書の有効期限が残っていることと、現在もその経路を信頼してよいことは別です。Web運営者は、自社証明書の期限監視に加え、利用する認証局や配信事業者の案内も確認できる体制にしておくと対応しやすくなります。

今回の問題を、以前扱った名前制約の検証差と混同しないことも重要です。今回は秘密鍵の侵害を受けた信頼の取り消しと、その情報をクライアントへ届ける経路が中心です。証明書に関するニュースという共通点だけで、異なる原因と対策を一つにまとめることはできません。

OneCRLはブラウザー本体の更新と別の経路を持つ

MozillaのOneCRL導入時の解説は、失効させる中間証明書の情報をブラウザーへ配布し、ブラウザー本体の更新を待たずに保護を届ける仕組みを説明しています。この資料は2015年の背景説明であり、当時の普及率や初期仕様を現在の数値として引用するものではありません。

今回の公式発表では、OneCRLによる保護はFirefoxの更新や再起動を必要としないとしています。一方、20日の更新は、独自の設定によりOneCRLの配信を受け取れなかった少数の利用者にも対策を届ける目的を持ちます。配信済みという説明と、すべての実行環境で確認済みという結論を混同しないようにします。

運用上は、ブラウザーの実行ファイルと、別途届くセキュリティ用データを二つの管理対象として考えます。本体の版だけを記録しても、追加データが同期できるか分かるとは限りません。逆に追加データが届いていても、本体に含まれる他の修正を適用しなくてよいわけではありません。

出典：Mozilla：OneCRLの導入に関する技術解説（2015年）

更新の対象を利用チャネルに合わせる

Mozillaは20日、デスクトップとAndroid向けFirefox 158.0.1、Firefox ESR 115.43.1、ESR 153.5.1を案内しました。通常版のリリースノートも、更新したOneCRLの遮断リストを含み、Remote Settingsがポリシーで無効な場合やネットワークで利用できない場合を補うと説明しています。

ESR 115.43.1の勧告はCVE-2026-113470を掲載し、影響度をHighとしています。本稿では確認できた評価を使い、未確認のCVSSスコアは作りません。また、更新番号を単純に大小比較せず、各端末が使っている提供チャネルと配布元の案内に沿って判断します。

自社の台帳では、端末、OS、Firefoxのチャネル、配布元、実行中の版、担当者を対応させます。パッケージ管理や組織の配布ツールから提供される場合は、その経路で修正が取り込まれたか確認します。通常版のインストーラーを、互換性検証なしですべてのESR端末へ上書きする作業にはしません。

出典：Mozilla：Firefox 158.0.1リリースノート

社内の通信制限が配信を妨げていないか

MozillaのRemote Settings技術文書は、サーバーと設定情報を同期する仕組みを示しています。ネットワークやポリシーの制約がある端末では、通常のWeb閲覧ができても、別の配信先へ接続できるとは限りません。今回のリリースノートがこうした条件に言及しているため、組織管理の端末では確認する価値があります。

本サイトの提案は、設定を一括で解除する前に、管理ポリシー、プロキシ、通信制限、更新ログを担当者が照合する方法です。業務画面へアクセスできるから配信も正常と結論付けず、必要な配信経路の確認と、本体に対策を含む更新の適用を並行して進めます。

独自設定には運用上の理由がある場合があります。確認せずに安全性の設定を広く変えたり、すべての外部通信を許可したりする必要はありません。今回の対応に必要な更新を適切な配布方法で届け、将来の配信も継続できるかを別の改善項目として扱ってください。

出典：Mozilla：Remote Settings技術文書

Firefox以外のアプリは別に確認する

Mozillaは、NSS 3.131.1でも信頼する証明書リストを更新し、OneCRLを受け取らない下流のアプリケーションなどを保護すると説明しています。NSSのリリース告知も、ルート証明書の信頼削除を示しています。Firefoxを更新したことを、OSやすべてのアプリの信頼設定が変わった証拠にはできません。

自社のアプリでMozilla由来の信頼ストアやNSSを利用している場合、ライブラリーがOSのパッケージで入るのか、アプリに同梱されるのかを確認します。アプリ側が別の信頼ストアを使う場合は、その提供元の案内が必要です。あるブラウザーの対策を、別の実装へそのまま適用済みとして扱わないようにします。

今回の資料から、特定の業務アプリが必ず影響を受けるとは言えません。製品名と版、実際の検証経路、供給元の対応を確認し、対象かどうかを判断します。利用者が独断で証明書ファイルを削除するより、製品や配布元が示す更新を追う方が、変更の影響を管理しやすくなります。

出典：Mozilla：NSS 3.131.1のリリース告知

Webサイト側は証明書チェーンと公開先を確認する

サイト運営者は、利用する証明書の発行元だけでなく、CDN、ロードバランサー、オリジンサーバーのどこでTLSを終端するかを確認します。公開先やリージョンによって配信される証明書が異なる場合、ひとつの端末で見えた証明書だけで全体を判断しないようにします。

本サイトの点検案では、対象ドメイン、終端場所、証明書チェーン、管理事業者、更新担当を整理します。今回影響するか分からない場合は、契約先へ勧告と利用サービスを添えて照会します。証明書の会社名が似ているという理由だけで、すべての証明書を緊急交換する必要があるとは判断しません。

自社のサイトが正常に表示されたことも、利用者側の遮断情報が最新である証明にはなりません。サイトの配信設定とクライアントの保護状況を分けて確認します。接続を拒否された場合は、その原因を調べ、保護機能を外して表示させることを復旧方法にしないでください。

証明書警告を消すための例外登録をしない

業務を急ぐ場面で証明書警告が出ると、例外を登録したり、検証を無効にしたりしたくなることがあります。しかし、失効や信頼変更が原因なら、その警告を回避する操作は必要な防御を外す可能性があります。今回の問題の確認でも、警告が消えたことだけを成功条件にはしません。

開発用のスクリプトで証明書検証を無効にするオプションを使っていた場合、その設定が本番へ入っていないかを見直します。証明書の信頼を確認しない接続では、遮断情報を更新する目的そのものが生かせません。開発環境の例外は用途と範囲を限定し、本番の通信設定と分離して管理します。

不具合調査では、端末の時刻、接続先名、証明書チェーン、プロキシの有無、表示されたエラーを残します。警告の画面へ顧客情報や秘密を追記せず、必要な技術情報だけを担当者へ共有します。原因の特定前に、サイト側の秘密鍵を広い宛先へ送って確認してもらうような対応は避けてください。

更新と検証の完了条件を決める

Mozillaの更新手順は、インストール元により経路が異なることと、更新の適用には再起動が必要であることを説明しています。OneCRL単独の配信と本体更新の手順を混同せず、本体を更新した場合は再起動後に実行中の版を確認します。

下表は本サイトが提案する確認票です。保護が必要な端末とアプリを一つの「更新済み」でまとめず、利用する信頼情報と配布方法を対応させます。実際の攻撃用証明書を用意して試す必要はなく、正規の更新、設定の確認、業務上の正常な接続を組み合わせて検証します。

出典：Mozilla：Firefoxの更新方法

対象	確認すること	完了の根拠
Firefox本体	利用チャネルと配布元の修正	再起動後の実行中の版
Remote Settings	ポリシーと配信経路	管理者が同期経路を確認
NSS利用アプリ	同梱版と供給元の案内	製品更新と依存関係の記録
WebのTLS終端	チェーンと管理事業者	対象確認と正規接続の結果

公開資料から言える範囲

Mozillaの発表は秘密鍵の侵害と保護策を説明していますが、この記事が自社や国内の通信被害を確認したわけではありません。OneCRLによる遮断の時刻、20日の本体更新、NSSを通じた別アプリへの対応を区別して読むことが重要です。

Web運営では、証明書を発行して終わりではなく、信頼が変更されたときに、その判断が接続元へ届くことまで考える必要があります。今回は更新できない端末や独自の信頼ストアを使う処理を見つけ、警告を回避せずに必要な対策を届けられるかを点検する機会になります。