eMudhra、Web証明書事業から撤退へ　弱い秘密鍵問題でChrome・Firefoxなどが緊急遮断

今回のニュース

2026年10月22日、インドのデジタル認証事業者eMudhraが、Webサイト向けのグローバル証明書事業から撤退する方針だとReutersが報じました。背景にあるのが、eMudhra傘下の中間認証局（CA）8件で、秘密鍵が十分な強度を持たず、公開情報から現実的に復元できる状態だった問題です。

Google、Mozilla、Apple、Microsoftなどはすでに影響する証明書や鍵の信頼を止める対応を進めています。GoogleはChromeとAndroid向けの緊急遮断を配信し、さらに問題の証明書チェーンにつながるルート証明書「emSign ECC Root CA - G3」をChrome Root Storeから削除する予定です。

一方、eMudhraは自社インフラへの侵入やデータ漏えいは確認しておらず、問題は2025年4月の鍵生成工程にあったと説明しています。今回の件は「HTTPSだから無条件に安心」ではなく、HTTPSの信頼がどのように成り立ち、問題が起きたときにブラウザやOSがどう守るのかを知るうえでも重要な事例です。

要点

今回の問題で重要なのは、Webサイトそのものが直接ハッキングされたという話ではありません。HTTPSの「このサイトは本物だ」と証明する仕組みの一部である中間CAの秘密鍵が、異常に弱い状態で作られていたことです。

秘密鍵を第三者が使えると、本来は認証局しか発行できない証明書を偽造し、条件次第では別のWebサイトになりすますことが可能になります。Googleは、影響した6件のTLS用中間CAについて、遮断前にCertificate Transparency（CT）へ登録された証明書がなかったため、CTを強制するChromeなどでは偽証明書が使われた形跡はないと説明しています。

一般ユーザーが今すぐ行うべきことはシンプルです。ブラウザとOSを最新状態に保ち、証明書エラーが表示されたサイトでは「詳細設定から無理やり開く」といった回避をしないことです。

サイト運営者は、自分のTLS証明書が「emSign ECC Root CA - G3」につながる証明書チェーンかを確認し、該当する場合は別の信頼された証明書チェーンへ切り替える必要があります。

何が起きたのか

HTTPSでは、ブラウザとWebサイトの通信を暗号化するだけでなく、接続先が正しいサイトかどうかを確認するために「証明書」が使われています。その証明書を発行するのが認証局（CA）です。

通常は最上位のルートCAが直接すべての証明書を発行するのではなく、その下に中間CAを置き、中間CAが実際のWebサイト向け証明書を発行します。今回問題になったのは、eMudhraの中間CA8件です。

Googleによると、2026年10月17日に研究者から、8件の中間CAに対応する秘密鍵が危険な状態にあるとの報告を受けました。鍵は本来、事実上総当たりできないほど巨大な候補からランダムに選ばれる必要があります。しかし今回の鍵は乱数の強度が不足し、第三者が復元できる状態でした。

Mozillaも報告を受けた後、独自に秘密鍵を復元できたと記録しています。つまり「秘密鍵がどこかから盗まれた可能性がある」という段階ではなく、公開されている情報から鍵そのものを再現できてしまう生成上の問題だったことが確認されたわけです。

eMudhraは10月21日の声明で、2025年4月30日に実施した鍵生成作業のwrap/unwrap処理に不具合があり、本来の強い鍵とは別に弱い鍵が生成され、その弱い鍵がブラウザ向けの信頼ストア側へ公開されたと説明しています。

なぜ危険なのか　HTTPSの「鍵マーク」の前提が崩れる

HTTPSの鍵マークは「通信が暗号化されている」ことを示すだけではありません。ブラウザは証明書の署名を検証し、その証明書が信頼できる認証局につながっているかを確認します。

ところが、中間CAの秘密鍵を第三者が自由に使える状態になると、その第三者は「正規の認証局が発行したように見える証明書」を作れる可能性があります。もし利用者の通信を途中で横取りできる環境と組み合わせれば、偽サイトを本物に見せたり、通信内容を盗み見たり改ざんしたりする攻撃につながりかねません。

ただし、今回の問題を「すでにChrome利用者のHTTPS通信が大量に盗まれた」と解釈するのは正確ではありません。Googleは、影響するTLS用中間CAに連なる証明書が遮断前のCTログに存在しなかったことから、CTを強制するChromeなどでは偽証明書が利用できる状態ではなかったと説明しています。

重要なのは、危険な鍵が存在したことと、実際に攻撃被害が確認されたことを分けて考えることです。現時点では広範な悪用が確認されたと断定できる材料はありません。

ChromeやFirefoxはどう対応したのか

Googleは10月17日、報告を受けてから約2時間弱で、影響するTLS用中間CA6件の公開鍵情報をCRLSetで遮断しました。CRLSetはChromeが危険な証明書や鍵を迅速に拒否するための仕組みで、通常のChrome利用者はブラウザ本体を更新したり再起動したりしなくても保護を受けられます。

AndroidについてもGoogle Play開発者サービスを通じて同等の更新が配信されています。Googleは、多くの端末にはすでに反映されているとし、必要なら端末の再起動で更新を促せるとしています。

MozillaもFirefox向けにOneCRLを使って影響する証明書を遮断しました。また、こうしたオンライン更新を受け取れない環境向けにもFirefox本体の更新で対策を取り込んでいます。

Googleはさらに、「emSign ECC Root CA - G3」をChrome Root Storeから削除し、2026年10月27日（米国太平洋時間）朝から一般配信する予定です。これにより、そのルート証明書に依存した正規サイトでも、新しい証明書へ移行していなければChromeで接続エラーになる可能性があります。

一般ユーザーがやること

一般ユーザーが証明書の種類や認証局を一つずつ調べる必要はありません。重要なのは、ブラウザやOSが配信する信頼情報の更新を受け取れる状態にしておくことです。

まず、Chrome、Firefox、Edge、Safariなど普段使っているブラウザを最新状態にしてください。スマートフォンやパソコンのOS更新も、長期間止めたままにしない方が安全です。

そして今後数日、普段使っているサイトで突然「安全な接続ではありません」「証明書に問題があります」といった警告が出た場合、安易に警告を無視して接続しないでください。今回のルート証明書削除に伴い、サイト運営者側の証明書切り替えが間に合わず、一時的に正規サイトでエラーが出る可能性もあります。

その場合は、ブックマークや公式アプリ、公式SNSなど別の経路から運営者のお知らせを確認し、復旧を待つのが安全です。証明書エラーを突破してログイン情報やクレジットカード情報を入力することは避けてください。

サイト運営者・小規模事業者が確認すること

自社サイトや業務システムを管理している場合は、利用中のTLS証明書の「証明書チェーン」を確認してください。問題の対象は、単にeMudhraという名前がどこかにあるかではなく、「emSign ECC Root CA - G3」につながる証明書チェーンを使っているかどうかです。

Googleは、このルートにつながる証明書を使うサイト運営者に対し、Chrome Root Storeに含まれる別のPKI階層から新しいTLS証明書を取得し、直ちに切り替えるよう求めています。eMudhraも影響する顧客に交換用証明書を提供すると説明しています。

レンタルサーバーやクラウドサービスでHTTPSを自動管理している場合は、まずサービス事業者のお知らせを確認してください。証明書を自分で設定していないサービスでは、利用者側で手作業の入れ替えが不要な場合があります。

一方、社内システム、APIクライアント、古いサーバー、組み込み機器、独自の証明書バンドルを使うソフトウェアは注意が必要です。ChromeやFirefoxのような即時遮断の仕組みを使っていないことがあり、OSや証明書パッケージ、言語ランタイム、依存ライブラリ側の更新が必要になる場合があります。

「ブラウザで問題なく開けるから、サーバー間通信も安全」とは限りません。ブラウザと、それ以外のTLSクライアントは別々に確認するのが安全です。

現時点で分かっていること・分かっていないこと

eMudhraは、自社インフラへの侵入やデータ漏えいは確認していないと説明しています。また、影響した中間CAのうち本番投入されたのは1件で、影響した中間CAからエンドユーザー向け証明書は発行されていないとしています。

Googleも、対象のTLS用中間CAに連なる証明書が遮断前のCertificate Transparencyログに存在しなかったと説明しています。この点は、主要ブラウザ利用者にとって大きな安心材料です。

一方で、ブラウザ外のソフトウェアすべてが同じ速度で遮断情報を受け取るわけではありません。また、秘密鍵が復元可能な状態だった期間に、研究者以外の第三者が同じ問題に気付いていたかどうかを完全に証明することも困難です。

そのため、「被害はゼロだった」と断定するより、「主要ブラウザは迅速に保護され、現時点で大規模な悪用は確認されていないが、周辺ソフトウェアを含めた更新は続けるべき」と考えるのが妥当です。

まとめ

eMudhraの中間CAで起きた問題は、HTTPSを支える信頼の仕組みそのものに関わる重大な事故です。秘密鍵が弱ければ、攻撃者が正規の認証局になりすまして偽の証明書を作れる可能性があります。

一方、ChromeやFirefoxなど主要ブラウザは報告後すぐに対象を遮断し、GoogleはCertificate Transparencyの記録から、ChromeなどCTを強制する環境では遮断前にも偽証明書を利用できなかったと説明しています。必要以上に不安になるより、更新を止めないことと、証明書警告を無視しないことが重要です。

一般ユーザーはブラウザとOSを最新に保ち、証明書エラーが出たサイトで無理に先へ進まない。サイト運営者は自分の証明書チェーンを確認し、対象なら別の信頼された証明書へ切り替える。この2点が当面の実践的な対応です。

今回の件は、普段は意識しない「Webの信頼」が、認証局・ブラウザ・OS・ソフトウェア更新の連携で保たれていることがよく分かる事例でもあります。