Chrome・Firefoxが証明書を緊急遮断、認証局8件の秘密鍵に重大な欠陥：正規サイトへの影響も

デジタル証明書を発行するeMudhraの中間認証局8件で、証明書の署名に使う秘密鍵を第三者が容易に復元できる問題が発覚し、MozillaとGoogleが2026年10月20日に対応を公表した。問題のある鍵を信頼し続けるソフトウェアでは、通信に割り込める攻撃者が偽の証明書を使って接続先になりすまし、通信内容を盗み見たり改ざんしたりする恐れがある。主要ブラウザではすでに問題の証明書を遮断する措置が進んでいるものの、アプリが独自に使用する証明書の検証機能には、別途更新が必要な場合がある。

対策には、問題のある中間認証局の鍵や証明書だけを拒否する方法と、その上位にあるルート証明書を信頼対象から外す方法がある。後者は影響範囲が広く、問題のない証明書を使用する正当なサイトにも接続できなくなる可能性がある。そのため、利用者側ではアプリの検証機能を更新し、サイト運営者側では必要に応じて証明書を切り替えるという、両面での対応が求められる。

256未満の秘密値で、認証局の署名を偽造できる状態に

問題が見つかった8件の中間認証局証明書のうち、6件はWebサイトとのTLS通信に使うもので、残る2件はコード署名向けだった。Mozillaの公開調査記録によると、Wayneと名乗る報告者が各秘密鍵を使って作成した署名を提示し、実際に鍵を復元できたことを証明した。中間認証局の秘密鍵を第三者が入手できる状態になっていたことが、今回の問題の核心である。

通常、HTTPS通信では、ブラウザなどが信頼するルート認証局を起点として、中間認証局、接続先サイトの証明書へと続く署名のつながりを検証する。この仕組みを証明書チェーンと呼び、正当な認証局が発行した証明書かどうかを判断するために使われる。ところが、中間認証局の秘密鍵を第三者が入手すると、その認証局になりすまして新たな証明書に署名できてしまう。特定のWebサイトの証明書を1枚盗まれる場合とは異なり、任意のサイトを偽装する証明書を発行できる恐れがあるため、影響ははるかに広い。

今回の問題は、P-384という楕円曲線暗号で使用する秘密値が、8件すべてで256未満の整数になっていたことだ。本来、この秘密値は極めて大きな範囲から無作為に選ばれる必要がある。しかし、問題の鍵は最後の1バイトを除けばほぼゼロという状態で、候補となる値を調べれば容易に復元できた。Mozillaの担当者も、報告者が用いた手法を知らない状態で独自に秘密鍵を復元できたと説明している。これはP-384という暗号方式そのものが破られたのではなく、秘密鍵を生成する工程に問題があったことを意味する。

eMudhraが10月21日に公表した説明によると、問題の鍵は2025年4月30日に実施された鍵生成作業で作成された。同社は、鍵を安全に保護して移動するためのラップ・アンラップ工程で、本来の強い鍵とは別に弱い鍵が生成され、後者が公開されてしまったと説明している。鍵の生成にはハードウェアセキュリティモジュール（HSM）が使用されていたが、問題を引き起こした詳しい根本原因はまだ確定していない。そのため、今回の事象をHSM自体の欠陥と断定することはできない。

eMudhraによれば、問題の8件のうち7件は本番環境で使用されておらず、残る1件も含めて顧客向けの末端証明書は発行していなかったという。また、問題が公表される前に秘密鍵が復元されたり、悪用されたりしたことを示す証拠は把握していないとしている。ただし、これは同社による正規の証明書発行や、現時点で確認できた悪用の証拠についての説明だ。第三者が弱い秘密鍵を復元して偽の証明書を作成できるという技術的な危険性とは区別する必要があり、悪用がなかったと証明されたわけではない。

ChromeとFirefoxは迅速に遮断、Androidにも追加修正

Mozillaの10月20日の発表によると、同社は10月17日20時06分（UTC）に問題の報告を受け、その日の22時59分までに、通常設定のFirefox利用者に対する遮断情報の配布を完了した。対応には、失効した証明書を拒否するための「OneCRL」という仕組みが使われた。OneCRLはブラウザ本体の更新や再起動を必要とせず、証明書の遮断情報を配布できる。今回もこの仕組みによって、報告を受けてから約3時間以内に、通常設定のFirefoxへ保護措置が届けられた。

Mozillaはさらに10月20日、Firefox 158.0.1と、長期サポート版のFirefox ESR 115.43.1、ESR 153.5.1を公開した。これらの更新は、独自の設定などによってOneCRLの遮断情報を受信できなかった利用者にも、保護措置を届けるためのものだ。翌21日にはAndroid版Firefox 158.0.2も追加で公開され、一部の端末で起動直後に同梱の遮断リストが適切に適用されない問題を修正している。このように、遮断情報を受信できたかどうかだけでなく、実際にブラウザがその情報を適用しているかも重要になる。

一方、Googleの10月20日の説明によると、Chromeは10月17日19時45分（UTC）に、問題の鍵を遮断するための「CRLSet」の更新を反映した。CRLSetでは、証明書に含まれる公開鍵情報（SPKI）のハッシュ値を照合しており、同じ公開鍵を使う証明書もまとめて拒否できる。これにより、Chrome利用者はブラウザ本体を更新したり、再起動したりすることなく保護を受けられるようになった。

Android端末などにも、10月19日22時ごろ（UTC）、Google Play Servicesを通じて同等の更新が配布された。Googleは発表時点で大半のAndroid端末が更新を受信済みと説明し、端末を再起動することで即時更新を促せるとも案内している。ただし、これらの対応によってChromeや対象となるAndroidの証明書検証機能が保護されても、端末内のすべてのアプリが同じ仕組みを使用しているとは限らない。

今回の影響を評価するうえでは、Certificate Transparency（CT）も重要な役割を持つ。CTは、発行されたTLS証明書を公開ログに記録し、不正な発行を検出しやすくする仕組みだ。Googleによると、遮断措置が実施されるまでに、問題の6件の中間認証局につながるTLS証明書はCTログに記録されていなかった。そのため、CTの要件を強制するChromeなどのクライアントでは、これらの中間認証局から発行された偽の証明書を悪用できなかったと説明している。一方、この保護はCTを強制しないアプリにまで自動的に及ぶものではなく、証明書の検証方法によって危険性は異なる。

問題の証明書を遮断するか、ルート証明書を削除するか

認証局が証明書を失効させたとしても、それだけですべてのソフトウェアが問題の証明書を拒否するわけではない。証明書を検証するアプリが最新の失効情報を確認し、その結果を適切に反映する必要がある。MozillaのDennis Jackson氏が公開したソフトウェア運営者向けの助言によると、eMudhraは10月18日、相互署名に関わっていたSectigoは19日に対象の証明書を失効させた。

Jackson氏は、最新の失効情報を確実に確認し、確認できなければ接続を拒否する「フェイルクローズ」の動作を徹底しているクライアントであれば、追加対応は不要だと説明している。一方、失効情報を確認しないクライアントや、確認に失敗しても接続を許可する「フェイルオープン」の動作をするクライアントには対策が必要だ。つまり、認証局側で失効処理が完了していても、利用するソフトウェアの検証方法によっては危険な証明書を受け入れてしまう可能性がある。

対策としては、問題のある中間認証局の証明書や公開鍵を個別に拒否する方法が考えられる。この方法なら、影響を問題の証明書に限定しやすい。しかし、個別の中間認証局を遮断する仕組みを持たないソフトウェアでは、その上位にあるルート証明書を信頼対象から外す方法も選択肢となる。同じルート認証局の下には、今回の問題とは無関係な正当な中間認証局も存在するため、ルート証明書を削除すると、それらの認証局が発行した証明書を使用するサイトにも接続できなくなる恐れがある。

各社の公式発表を基に、対策の仕組みと更新後に確認すべき内容を整理すると、次のようになる。

対策・対象	遮断範囲と更新方法	更新後の確認事項
ChromeのCRLSet	問題の公開鍵情報（SPKI）を照合し、同じ鍵を使用する証明書を遮断	Chromeの保護措置が、別の証明書検証機能を使うアプリにも適用されるとは限らない
FirefoxのOneCRL・本体更新	対象証明書を遮断し、OneCRLを受信できない環境にも本体更新で保護を届ける	Android版では158.0.2への追加更新も確認し、遮断情報の受信と実際の適用を区別する
NSS 3.131.1・Chrome Root Storeの更新	emSign ECC Root CA - G3を信頼対象から削除	同じルートにつながる正当な証明書を使用する接続先についても、移行の必要性を確認する

この表は、各社が公表した対策を比較したものであり、独自の動作試験による結果ではない。重要なのは、中間認証局の鍵や証明書を個別に遮断する対策と、上位のルート証明書を信頼対象から削除する対策では、影響範囲が異なることだ。さらに、更新情報がアプリへ届いているか、そのアプリが実際にどの証明書検証機能を使っているかも、別々に確認しなければならない。

eMudhraは、ルート認証局の秘密鍵そのものは今回の問題の影響を受けていないと説明している。それでもMozillaとGoogleがルート証明書の削除を進めるのは、危険な中間認証局の鍵を個別に遮断できないソフトウェアも保護するためだ。MozillaはNSS 3.131.1で対象ルートを信頼リストから削除する方針を示しており、GoogleもChrome Root Storeからの削除を決めた。問題のある中間認証局だけを遮断する場合より影響は広くなるが、個別の遮断情報を利用できないクライアントへの対策にもなる。

アプリごとの証明書検証と、サイト側の証明書移行が必要

今回の問題を受け、Cloudflareは開発者に対し、アプリが実際にどの仕組みでTLS証明書を検証しているかを確認するよう求めている。同社の10月20日の技術解説によると、外部APIなどに接続するアプリは、HTTPライブラリや言語ランタイム、OS、独自の信頼設定など、さまざまな仕組みに証明書の検証を任せている場合がある。そのため、アプリが使用するSDKだけを更新しても、実際に証明書を検証する仕組みの設定や動作が変わるとは限らない。

例えば、OSの信頼ストアを更新して問題の証明書を拒否するようにしても、アプリが独自の証明書ストアを同梱していれば、その変更が反映されない可能性がある。Cloudflareも、自社が使用する共通の信頼ストアや基盤イメージを更新するとともに、独自の信頼ストアを持つアプリについては個別に評価し、必要な対策を施した。また、更新内容を実際の稼働環境へ反映するため、再読み込みや再起動、イメージの再配備も組み合わせている。Cloudflare Tunnelで使用するcloudflaredについては、バージョン2026.10.2への更新を案内し、コンテナ環境では修正版イメージを再配備するよう求めた。

更新後の確認も、アプリが実際に使用するTLSの検証経路で実施する必要がある。Cloudflareは、同じ端末のブラウザで問題が解消されたとしても、バックグラウンドで動作するサービスまで保護されたとは限らないと指摘している。同様に、curlで検証に成功しても、対象アプリが別の証明書検証機能を使用している場合、その結果をアプリの安全性の証明には使えない。証明書の検証に失敗するようになった場合も、接続を復旧させるために証明書検証を無効化してはならない。検証を無効にすると、今回の更新で回復させようとしている接続先の認証機能そのものが失われてしまうためだ。

一方、Webサイトの運営者には、ルート証明書の削除によって正当な接続ができなくなる事態を避けるための対応が求められる。Googleは10月20日の発表で、Chrome Root Storeに依存するすべての端末に対し、emSign ECC Root CA - G3の削除を10月27日朝（米太平洋夏時間、PDT）に反映する予定だと説明した。Chrome CanaryやChrome Betaなどの先行版では、さらに早い段階で変更が適用される。同ルートにつながるTLS証明書を使用しているサイト運営者には、Chrome Root Storeに含まれる別の信頼済み認証局の証明書を速やかに取得し、導入するよう求めている。

eMudhraも10月22日の追加発表で、代替手段としてSectigoが発行する証明書を顧客に提供すると表明した。問題の中間認証局が発行した証明書を使用していなくても、削除対象のルート認証局につながる正当な証明書を利用している場合には、接続不能を避けるための移行が必要になる可能性がある。つまり、今回の対策は危険な証明書を拒否するだけでは完了せず、必要な接続を維持するための証明書移行も含まれる。

利用者側では、問題のある鍵を確実に拒否できるよう、アプリやその依存ライブラリ、証明書ストアを更新する必要がある。同時に、サイト運営者側では、ルート証明書の削除によって正当な接続が失われないよう、必要に応じて証明書を移行しなければならない。10月27日に予定されるChrome Root Storeの変更を前に、双方が実際の稼働環境で証明書の検証経路を確認し、危険な証明書の遮断と正当な接続の維持を両立できているかが、対応完了を判断する重要な条件となる。