eMudhraの中間CA秘密鍵が復元可能に ―証明書の信頼問題と企業のTLS対策

HTTPS通信では、サーバー証明書の検証によって接続先の正当性を確認します。しかし、その信頼の根拠となる認証局の秘密鍵が第三者に悪用されると、なりすましの危険が生じます。2026年10月、認証局eMudhraの中間CA証明書8件に対応する秘密鍵が、第三者でも容易に復元できる状態だったことが明らかになりました。MozillaやGoogleは対象証明書の信頼を遮断する対策を進め、関連ソフトウェアの更新も行われています。企業が確認すべきなのは、自社サイトで使用するSSL／TLS証明書だけではありません。外部サービスへ接続する業務アプリの証明書検証機能も対象です。本記事では、問題の概要と影響範囲、API通信を含むシステムの確認事項を整理します。

※本記事は2026年10月22日時点で公表されている情報を基に作成しています。認証局の調査結果や各ソフトウェアの対応状況は、今後変更される可能性があります。

中間証明書とはサーバー証明書を信頼につなぐ役割

中間証明書は、ルート認証局から個々のサーバー証明書へ信頼をつなぐ証明書です。一般的な証明書チェーンでは、ブラウザやOSなどが信頼するルート証明書を起点に、中間CA証明書、その下のサーバー証明書へと署名の関係が続きます。接続する側はこの関係などを検証し、相手の証明書を受け入れてよいか判断します。

Webサイトの運営者が持つ秘密鍵と、中間CAが証明書に署名するための秘密鍵は役割が異なります。後者を第三者が使用できる状態になると、攻撃者は対象の中間CAが正規に発行したかのように見える証明書を偽造できるおそれがあります。今回、問題となったのはこの署名用の秘密鍵です。通信経路に介入できる攻撃者が偽の証明書を提示し、接続側が受け入れると、通信内容を読み取られたり書き換えられたりするおそれがあります。

図1：中間CAの秘密鍵とサーバー証明書の信頼の関係

eMudhraの中間CAで秘密鍵の生成に問題が発覚

Mozillaの調査記録によると、対象8件のうち6件はTLS用、2件はコード署名用です。Mozillaは2026年10月17日20時06分（UTC）に報告を受け、通常設定のFirefox向けには同日22時59分までにOneCRLによる遮断を配信しました。日本時間では10月18日5時06分の受領から、同日7時59分までの対応です。対象の鍵は楕円曲線暗号P-384を使っていましたが、秘密鍵の値はすべて256未満の整数でした。独立して検証した研究者Scott Helme氏も、公開証明書から対象の鍵をノートPCで1秒未満に復元できたと報告しています。十分なランダム性を持つ値が必要なところ、極端に小さな値が使われていたことが問題であり、適切に生成されたP-384の鍵まで容易に復元できるという話ではありません。

eMudhraは、2025年4月30日の鍵生成作業で、鍵を移送するためのwrap/unwrap工程に問題があり、正常な鍵とは別に弱い鍵が生成されたと説明しています。同社はHSM（ハードウェアセキュリティモジュール）を使用していたとしていますが、10月21日の更新時点で正確な根本原因は確定していません。現段階では、同社が説明する作業工程の問題と、今後の調査で確定する原因を分けて捉える必要があります。

ブラウザだけでなく業務アプリの証明書検証も確認

Chromeは10月17日に対象TLS中間CAの公開鍵をCRLSetで遮断しました。Googleによると、その遮断前に対象の中間CA配下のTLS証明書はCertificate Transparency（CT）のログに登録されていませんでした。このため、CTを必須とする標準設定のChromeなどでは、対象CAを使った偽造証明書が信頼される状態ではなかったと説明しています。

CTは、証明書の発行を公開ログで検証できるようにする仕組みです。認証局が証明書を失効させたという情報や、ブラウザ独自のブロックリストとは役割が異なります。失効情報やブロックリストを受け取らないアプリに、ブラウザと同じ対策が自動的に行き渡るとは限りません。業務アプリで証明書を検証するのは、HTTPライブラリやOS、独自の信頼ストアなどです。SDKだけの更新で対策が済むとは限りません。自社サイトの証明書の発行元が別でも、外部APIへ接続するアプリが対象CAを信頼する場合は確認が必要です。

図2：証明書を提示する側と検証する側の確認範囲

中間CA証明書の失効とルートCAの信頼取り消し

eMudhraは、問題の8件の中間CAからエンドユーザー向け証明書を発行していなかったと説明しています。ただし、それだけで第三者による偽造の可能性がなくなるわけではありません。誰かが秘密鍵を復元し、認証局の正規の発行手続きを経ずに証明書を作ることが問題だからです。

Mozillaは、中間CAだけを個別に拒否する仕組みを持たないソフトウェアも保護するため、上位のルート証明書「emSign ECC Root CA – G3」の信頼を緊急に取り消す方針を示しました。GoogleもChrome Root Store v43で同ルートを削除する予定です。Googleが示した安定版への反映予定は、10月27日午前の米国太平洋夏時間で、10月22日時点では今後の対応に当たります。

ルートの信頼が外れると、問題の弱い鍵を使っていない別の中間CA配下であっても、そのルートにつながる正規のサーバー証明書が検証に失敗する場合があります。eMudhraは当初、移行が必要な証明書を約3万件と見積もりました。この数字は被害件数やWebサイト数ではありません。対象の階層を利用している場合は、有効期限を待たず、提供元の案内に沿って代替の証明書チェーンへ移行する必要があります。

FirefoxやGoなどの修正版と適用時の注意

Mozillaは10月20日、OneCRLの更新を受け取れない設定の利用者も保護するため、Firefox 158.0.1、Firefox ESR 115.43.1／153.5.1を公表しました。さらにAndroid版は10月21日に158.0.2が公開され、起動時に同梱のOneCRLブロックリストを適用する処理が修正されています。Android版では158.0.1だけを確認して対応済みとせず、この追加修正を含む更新を適用します。

Go 1.27.3および1.26.10では、対象の中間CA証明書を含む証明書チェーンを検証時に拒否する処理が追加されました。Goの脆弱性情報ではCVE-2026-111943、GO-2026-6809として管理されています。Go製アプリを運用する場合は、修正を取り込んだ製品版の有無を確認し、自社開発なら修正版でビルドした実行ファイルを配備することが対応になります。CloudflareはWARPなどのクライアントとcloudflaredの更新を公開しています。コンテナやアプリの依存関係も確認し、必要な再起動・再配備まで行います。

証明書の期限管理に検証経路の管理を加える

まず、WebサイトやAPIが提示する証明書チェーンを把握し、信頼が取り消される階層に依存していないかを確認します。同時に、外部のサービスへ接続する業務アプリについて、使用している証明書の検証機能と信頼ストアを調べます。証明書を提示する側と検証する側を分けると、証明書の交換が必要なのか、ソフトウェアやCA証明書の更新が必要なのかを整理できます。更新後は、実際の業務アプリで動作を確認します。ブラウザでの確認結果を、別の検証機能を使うバッチ処理やAPIクライアントの安全性の根拠にはできません。証明書エラーが出ても検証を無効にせず、チェーンや設定の原因を調べます。

今回の事案は、サーバー証明書が有効期限内であっても、認証局に対する信頼の変更によって証明書の交換やソフトウェアの更新が必要になることを示しています。企業には、証明書の発行元や有効期限だけでなく、証明書チェーンや検証に使用するソフトウェア、更新の管理体制まで把握し、継続的に確認することが求められます。

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

中間証明書とは サーバー証明書を信頼につなぐ役割