インドの認証局eMudhraで中間認証局（中間CA）の秘密鍵を容易に復元できる問題が発覚した後、第三者が生成した大量のTLS証明書がCertificate Transparency（CT）ログへ登録されていたことが明らかになりました。Mozillaの不具合管理システム「Bugzilla」に10月26日付で投稿された調査によると、2026年10月20日9時40分から21日22時02分（UTC）までに、問題のある6件の中間CA鍵で署名された証明書10万7,107件が公開ログで確認されました。このうち10万6,050件は、google.com を対象にした実証用（PoC）の証明書です。
これらはGoogleが発行を依頼した正規の証明書ではなく、eMudhraが通常のドメイン所有者確認を経て発行したものでもありません。秘密鍵を再現できる状態だったため、第三者が任意のドメイン名を記載した証明書に署名し、CTログへ提出できたことを示しています。Googleのサービスで10万件の通信傍受が起きたという発表ではありません。
eMudhraの証明書大量登録のサマリー
発端はeMudhraの中間CA証明書8件で秘密鍵を復元できる問題。TLS証明書用が6件、コード署名用が2件。
研究者からの報告は2026年10月17日（UTC）。eMudhraは翌18日に8件を失効させました。
10月20日9時40分～21日22時02分（UTC）、6件の問題のある鍵で署名された証明書10万7,107件がCTログに登録されたとの調査結果がBugzillaに投稿されました。
うち10万6,050件は、証明書のSAN（Subject Alternative Name）にgoogle.comのみを含むPoCです。
登録が確認されたのはe-Szignóの「2026h2」「2027h1」ログ。10万6,058件はSectigoによるクロス署名経路に連なっていました。
CTログへの登録はドメイン所有者による発行承認や、ブラウザからの信頼を意味しません。
ChromeやFirefoxは問題の中間CAを遮断。Mozillaは対象ルート「emSign ECC Root CA – G3」の信頼削除も進めています。
eMudhraは10月22日に世界向けSSL/TLS証明書事業からの撤退を発表し、既存顧客の証明書切り替えを進めています。
項目
確認内容
認証局
eMudhra（emSign）
問題
中間CAの秘密鍵が極端に弱く、公開情報から復元可能
対象の中間CA
8件（TLS用6件、コード署名用2件）
10月20～21日のCT登録数
107,107件（Mozilla Bugzillaへの報告値）
google.comを対象とするPoC
106,050件
CTログ
e-Szignó 2026h2／2027h1
中間CAの失効
2026年10月18日（UTC）
ブラウザ側の対応
問題の中間CAを遮断、関連ルートの信頼削除を推進
利用企業への影響
古い証明書検証実装や独自信頼ストアでは、更新・差し替え状況の確認が必要
CTログに10万7,107件、約99％はgoogle.com向けPoC
MozillaのBugzilla「eMudhra: Private key compromise of Intermediate Certificates」には、10月26日付のコメントでCTログの検証結果が投稿されています。確認対象は、問題のあるTLS中間CA鍵6件のいずれかで署名された証明書で、公開ログ上では電子署名がそれぞれ対応するCA公開鍵で検証できたと報告されています。
特徴的なのは、大部分がgoogle.comを対象とする実証用証明書だった点です。10万6,050件は全体10万7,107件の約99.0％に当たります。報告には、そのほかemsign.filippo.ioを対象とした証明書や、emudhra.salesforce.comを含む事前証明書（precertificate）の例も挙げられています。
ただし、CTログで多数の証明書が見つかったことを、そのまま多数のWebサイトが乗っ取られた証拠と扱うことはできません。ログ上の登録件数は、通信に使われた証明書の件数でも、被害サイト数でもありません。また、PoC以外の登録分すべてが犯罪目的だったと断定できる情報も示されていません。
なぜ失効済みの中間CAから作られた証明書がCTログに載るのか
Certificate Transparencyは、TLS証明書の発行状況を公開の追記型ログへ記録し、認証局の誤発行や不審な発行を第三者が発見できるようにする仕組みです。RFC 9162では、ログへの提出、暗号学的な検証、記録の監査などが規定されています。
通常、認証局がWebサイト向けの証明書を正規発行する際には、申請者が対象ドメインを管理していることを確認します。しかし今回、問題のある中間CAの秘密鍵そのものを第三者が復元できたため、認証局の正規の発行処理を使わずに、別の人物が任意のドメイン名を記載した証明書へ署名できました。
CTログは、提出された証明書の暗号学的な整合性や受け付け条件を検査して記録するもので、各ドメインの管理者に対して発行を許可したかどうかを問い合わせる制度ではありません。したがって、署名が成立していること、CTログに載っていること、ブラウザが実際のTLS接続で信頼することは、それぞれ別の判定です。
今回のCTログの大量登録は、秘密鍵の問題が公知になった後で第三者にも証明書生成を実行できたことを可視化しました。一方、ログに記録された証明書が有効なTLS接続に使われたかどうかは、CTの登録数だけでは分かりません。
関連資料
AI時代の脆弱性管理・パッチ管理｜運用見直しのポイントと製品選定の確認事項
脆弱性の優先順位付けから修復、暫定防御、パッチ管理まで、運用見直しと製品選定で確認したいポイントをまとめた資料です。
資料提供元：株式会社アズジェント
脆弱性管理の資料を見る
証明書の失効とブラウザの遮断は進むも、すべてのクライアントが同じ挙動とは限らない
Mozillaは10月17日（UTC）、Firefox向けのOneCRLを利用して問題のある中間CAを遮断しました。ChromeもCRLSetで該当するTLS中間CAの公開鍵識別子（SPKIハッシュ）をブロックしています。eMudhraは10月18日に8件を失効させ、Sectigoが同じ鍵に対して行ったクロス署名にも対応が取られました。
しかし、業務システム、古い組み込み機器、独自実装のTLSクライアントは必ずしもブラウザと同じ失効情報や信頼ストアを利用しません。Bugzillaの報告によると、CTログ上の証明書の大多数には末端証明書自身の失効確認先が記載されておらず、末端証明書だけを確認するクライアントでは、中間CAが失効しているか判断できない場合があります。
問題は単に「失効確認を全くしない製品」に限りません。証明書チェーンの途中まで失効を検証しない実装、失効情報を取得できない際に接続を許す設定、更新されない信頼ストアでも保護が不十分となる可能性があります。このため、Mozillaは中間CAの遮断に加え、ルート証明書「emSign ECC Root CA – G3」の信頼を取り消す対応を進めています。
なお、証明書の偽造だけで任意のユーザーの通信を自動的に読み取れるわけではありません。攻撃者が通信経路を操作できるなどの条件が重なり、さらにクライアントが不適切な証明書チェーンを信頼した場合に、なりすましや中間者攻撃につながります。
eMudhraは世界向けSSL/TLS証明書事業から撤退、顧客の証明書移行へ
eMudhraは10月22日、世界向けSSL/TLS証明書事業から自主的に撤退する方針を発表しました。10月26日に更新した公式説明では、鍵生成時のスクリプトの誤りが弱い鍵の発生につながったと認める一方、同社のインフラ侵害や顧客データ漏えいは調査で確認されていないと説明しています。
同社は問題の8件の中間CAから自社が正規の末端証明書を発行していなかったとしています。この説明は、第三者が復元した秘密鍵で証明書を生成し、CTログへ大量登録した事実と矛盾しません。「認証局が正規発行した証明書」と「認証局を経由せず第三者が偽造した証明書」は別だからです。
また、Mozillaの公開議論では、信頼削除の対象となる「emSign ECC Root CA – G3」配下の証明書について、およそ3万件の移行が必要になるとの当時のeMudhra側推計が示されました。これは偽造された10万7,107件とは別の数字です。eMudhraは自社のG1 RSAルートを引き続きサポートするとともに、Sectigoが正規発行する代替証明書の提供などを案内しています。
企業の情報システム部門が確認したいこと
ブラウザの緊急更新が完了していても、社内で動くすべてのTLSクライアントに対策が行き渡ったとは限りません。特に認証局の信頼情報がソフトウェアやコンテナに固定されている環境では、OS側の更新とは別の確認が必要です。
対象
確認・対応する内容
社員端末・ブラウザ
Chrome・Firefoxなどの更新および失効情報配信の有効化。独自設定で失効・証明書検証を無効にしていないか確認する
Linuxサーバー・コンテナ
ca-certificatesや証明書バンドルの更新状況を把握し、古いコンテナイメージを再ビルド・再配布する
Java・Python・Go製アプリ
OSとは別の信頼ストアや同梱CAバンドルを確認する。必要なセキュリティ更新・再ビルドを適用する
API連携・業務システム
対象中間CAやルートに連なる接続先を洗い出し、更新後にTLS接続障害が起きないか検証する
IoT・ネットワーク機器
ファームウェア更新、CRL/OCSP確認、ルート証明書の取り扱いを製品ベンダーへ確認する
証明書管理担当
自社サイト・APIが対象ルートを利用していないか棚卸しし、必要に応じて別の証明書チェーンへ移行する
証明書の検証エラーが発生した場合、検証機能を無効にして復旧する方法は避けます。原因が失効した認証局への依存であれば、正規の証明書・信頼チェーンへの切り替えを進める必要があります。併せて、自社ドメインに対する予期しない証明書の発行をCT監視で把握できる仕組みを点検します。ただし、CT監視は事後の検知手段であり、偽造証明書をクライアントが受け入れないための検証・更新とは役割が異なります。
今回の秘密鍵問題そのものとブラウザ・OSの緊急対応は、eMudhraの中間認証局8件に関する既報で整理しています。関連して、Goの証明書検証に関する緊急更新やPython・pip・certifiの対応でも、アプリケーションごとに更新箇所が異なる点を紹介しています。
出典
この記事をシェアする
メールマガジン
最新のセキュリティ情報やセキュリティ対策に関する情報をお届けします。
Googleアカウントへのログインが必要です
投稿者：三村
セキュリティ製品を手がける上場企業にて、SOC（セキュリティオペレーションセンター）運営およびWebアプリケーション脆弱性診断の営業に8年間従事。その後、システムエンジニアへ転身し、MDMや人事系SaaSの開発に携わる。
8年の実務経験と開発者としての知見を活かし、「セキュリティ対策Lab」ではダークウェブ調査、セキュリティインシデントの分析、および高度なセキュリティ対策解説の執筆・編集を統括しています。
LinkedIn(外部サイト)