eMudhra 中間CAの鍵の危殆化：何が変わったか、自分の環境をどう確認するか

保存済みの出典と照合した最終確認日: 2026年10月26日

何が起きたか

• 2026年10月17日 に Chrome Root Program が、eMudhra の下位CA証明書8件の秘密鍵が危殆化したとの報告を受けました。鍵は十分なランダム性なしに生成されており、これらのCAをまだ信頼しているクライアントに対しては、誰でも受け入れられる偽の証明書を作れる状態でした。

  出典: Chrome and Android Security Teams

  引用文

  On Saturday, October 17, 2026, at 18:05 UTC, the Chrome Root Program received a report from a security researcher regarding the compromise of private keys associated with eight eMudhra subordinate Certification Authority (CA) certificates. The private keys for these certificates were generated with insufficient randomness (i.e., weak cryptographic entropy), enabling anyone to forge trusted HTTPS certificates to impersonate any website against clients that have not yet removed trust in those CAs.

• eMudhra は、グローバルTLS事業の中間発行CA 8件を、公開されていた鍵が脆弱だったため失効させたこと、およびそれらが同社のECCルートの下にあることを公表しています。

  出典: eMudhra

  引用文

  Eight intermediate (issuing) CAs in our Global TLS business were revoked because their published keys were weak. These intermediates sit under eMudhra's ECC root.

Chrome は eMudhra の ECC ルートを削除する

• Chrome は Chrome Root Store から emSign ECC Root CA - G3 を削除しました。この削除は、Chrome Root Store に依存するすべての端末に 2026年10月27日（太平洋時間）に反映される見込みで、Canary と Beta ではそれより早く反映されます。このルートにチェーンする正規の証明書の一部は、Chrome で動作しなくなります。

  出典: Chrome and Android Security Teams

  引用文

  we have also removed emSign ECC Root CA - G3 (the root certificate that signed the compromised CA certificates) from the Chrome Root Store. Some legitimate certificates chaining to this root will cease to function in Chrome as a result, and eMudhra has committed to working with impacted subscribers to migrate customers off of the impacted root. This root removal is expected to be released for all devices relying on the Chrome Root Store Tuesday morning, October 27, 2026 PDT, and sooner on prerelease channels like Chrome Canary and Chrome Beta.

• Chrome は、emSign ECC Root CA - G3 にチェーンする証明書を使っているサイト運営者に対し、障害を避けるため、Chrome Root Store に含まれる別のPKI階層から新しいTLS証明書をただちに取得して導入するよう求めています。

  出典: Chrome and Android Security Teams

  引用文

  To avoid breakage, website operators with certificates chaining to emSign ECC Root CA - G3 must immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store

誰が何を変更したか

Microsoft: 前回の確認時点で、このページからリンクできる公式の声明は見つかっていません。プロジェクトに専用のイベントページがある場合は、リリース一覧への案内を各項目に付けています。

• Mozilla のインシデント記録は、次の中間CA 8件を挙げています。うち6件はTLS証明書、2件はコード署名用です。

  • EM EV TLS CA - G3B (eMudhra BV)
  • EM OV TLS CA - G3B (eMudhra BV)
  • EM DV TLS CA - G3B (eMudhra BV)
  • EM EV TLS CA - G3C (eMudhra Inc)
  • EM OV TLS CA - G3C (eMudhra Inc)
  • EM DV TLS CA - G3C (eMudhra Inc)
  • EM OV CS CA - G3B (eMudhra BV)
  • EM OV CS CA - G3C (eMudhra Inc)

  出典: Mozilla (Bugzilla)

  引用文

  6 of the impacted certificates are for TLS and trusted by the Chrome, Mozilla, Microsoft and Apple root programs. The other two certificates are for codesigning and trusted by Microsoft

  EM EV TLS CA - G3B (eMudhra BV), CCADB A012304

  EM OV TLS CA - G3B (eMudhra BV), CCADB A012308

  EM DV TLS CA - G3B (eMudhra BV), CCADB A012302

  EM EV TLS CA - G3C (eMudhra Inc), CCADB A012296

  EM OV TLS CA - G3C (eMudhra Inc), CCADB A012300

  EM DV TLS CA - G3C (eMudhra Inc), CCADB A012294

  EM OV CS CA - G3B (eMudhra BV), CCADB A012306

  EM OV CS CA - G3C (eMudhra Inc), CCADB A012298

• Mozilla は影響を受ける証明書を OneCRL で Firefox 上でブロックし、OneCRL の更新を受け取れなかった可能性のあるクライアントにも反映されるよう、Firefox 158.0.1、Firefox ESR 153.5.1、Firefox ESR 115.43.1 を公開しました。

  出典: Mozilla Security Blog · イベントページ: CVE-2026-113470 (英語ページ)

  引用文

  Mozilla engineers responded immediately, blocking the affected certificates in Firefox using OneCRL , Mozilla’s centralized list of revoked certificates.

  Today, we are also releasing Firefox 158.0.1 for Desktop and Android, along with Firefox ESR 115.43.1 and Firefox ESR 153.5.1 . These releases will distribute this protection for a minority of users whose custom settings may have prevented them from receiving the OneCRL update.

• Apple は、これらの中間CAに関する12件の証明書を 2026年10月19日 からブロックし始めました。macOS の一部のコマンドラインツールは、独自の証明書ファイルを参照するため、今後のソフトウェアアップデートまで受け入れてしまう場合がある、と Apple は説明しています。

  出典: Apple Support

  引用文

  On 19 October 2026, Apple began blocking these 12 certificates on Apple devices.

  check certificates against /etc/ssl/cert.pem and can still accept these certificates until a future software update.

• OpenJDK の脆弱性アドバイザリ（CVE-2026-114820）は、27.0.1.0.2、25.0.5.0.2、21.0.13.0.2、17.0.21.0.2、11.0.32.1、8u504 およびそれ以前のリリースを影響対象として挙げています。

  出典: OpenJDK Vulnerability Group

  引用文

  The affected versions are 27.0.1.0.2, 25.0.5.0.2, 21.0.13.0.2, 17.0.21.0.2, 11.0.32.1, 8u504, and earlier.

  CVE-2026-114820 security-libs/ javax.net.ssl 9.1

• OpenJDK はこの変更を JDK-8395690 として管理しています。単体で配布されたランタイムについては、このIssueをリリースノートに記したベンダー版へ更新し、まだ提供されていなければ、次の4つのルートをランタイムの cacerts から削除して再起動するよう案内しています。

  • emsignrootcag1
  • emsignrootcag2
  • emsigneccrootcag3
  • comodoaaaca

  出典: OpenJDK

  引用文

  The runtime’s release note should document that it fixes issue JDK-8395690, CVE 2026-114820.

  $ keytool -delete -cacerts -alias "emsignrootcag1 [jdk]" $ keytool -delete -cacerts -alias "emsignrootcag2 [jdk]" $ keytool -delete -cacerts -alias "emsigneccrootcag3 [jdk]" $ keytool -delete -cacerts -alias "comodoaaaca [jdk]"

• OpenJDK のソースリポジトリでは、8395690 のコミットが、eMudhra の emSign ルート3件（emsignrootcag1、emsignrootcag2、emsigneccrootcag3）と comodoaaaca の既定の cacerts ファイルを削除しています。

  出典: OpenJDK (GitHub)

  引用文

  8395690: CA certificate improvements

  Expand all lines: src/java.base/share/data/cacerts/emsignrootcag1 - 29 Lines changed: 0 additions & 29 deletions Load diff This file was deleted.

  Expand all lines: src/java.base/share/data/cacerts/emsignrootcag2 - 39 Lines changed: 0 additions & 39 deletions Load diff This file was deleted.

  Expand all lines: src/java.base/share/data/cacerts/emsigneccrootcag3 - 22 Lines changed: 0 additions & 22 deletions Load diff This file was deleted.

  Expand all lines: src/java.base/share/data/cacerts/comodoaaaca - 32 Lines changed: 0 additions & 32 deletions Load diff This file was deleted.

• Python は ssl モジュールに、侵害が判明している証明書の拒否リストを追加しました。リストにある証明書を含むチェーンは、SSLContext のポリシーにかかわらず拒否されます。追跡用の記録は CVE-2026-115557 で、公式の変更履歴が挙げているリリースはイベントページで確認できます。

  出典: Python Security Response Team · イベントページ: CVE-2026-115557 (英語ページ)

  引用文

  [CVE-2026-115557] Distrust compromised intermediate certificates in ssl module

  Python has added a denylist for known compromised certificates to the "ssl" module to ensure user safety even without certificate revocation configured. Known compromised certificates on this denylist will automatically be rejected regardless of the SSLContext policy configuration.

• Electron は、Chromium のネットワーク層と Node.js の tls、https、fetch に同じブロックを追加しました。アドバイザリはアプリ側の回避策を挙げておらず、修正済みの Electron（44.9.1、43.8.1、42.11.16、または最新ラインで挙げられているプレリリース）を使ってアプリをビルドし直す必要があります。

  出典: Electron (GitHub Security Advisory) · イベントページ: CVE-2026-115570 (英語ページ)

  引用文

  This Electron update adds the same block to both Chromium networking and Node.js tls , https and fetch .

  There are no app side workarounds, you must update to a patched version of Electron.

  Fixed Versions 45.0.0-beta.6 44.9.1 43.8.1 42.11.16

• Electron のアドバイザリは、同じ緩和策を出したソフトウェアとして Go を挙げています（CVE-2026-111943）。

  出典: Electron (GitHub Security Advisory) · イベントページ: CVE-2026-111943 (英語ページ)

  引用文

  Other software has shipped the same mitigation, including Go (CVE-2026-111943)

• Go の go1.27.3 と go1.26.10 は、いずれも 2026年10月19日 にリリースされ、crypto/x509 パッケージのセキュリティ修正を含んでいます。CVE レコードと Go 公式のエントリはイベントページに載せています。

  出典: The Go Project · イベントページ: CVE-2026-111943 (英語ページ)

  引用文

  go1.27.3 (released 2026-10-19) includes security fixes to the crypto/x509 package.

  go1.26.10 (released 2026-10-19) includes security fixes to the crypto/x509 package.

自分の環境を確認する

これらのコマンドはお使いのマシン上で実行され、そこにインストールされているもの（バージョン、発行者、有効期間、信頼ストアのエントリ）を読むだけです。PatchBell があなたのシステムをスキャンすることはありません。

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -dates

keytool -list -cacerts -storepass changeit | grep -i -E 'emudhra|emsign|comodoaaa'

python3 -c "import certifi; print(certifi.where())" | xargs grep -i -E 'emudhra|emsign'
python3 -c "import ssl; print(ssl.get_default_verify_paths())"

trust list | grep -i -E 'emudhra|emsign'
ls /etc/ssl/certs | grep -i -E 'emudhra|emsign'

certutil -store Root | findstr /i "emudhra emsign"

証明書を入れ替える

1. eMudhra または emSign のルートにチェーンしている証明書をすべて洗い出します。公開しているホスト名ごとにサイトの確認コマンドを実行し、独自の信頼ストアを持つ社内サービスも調べてください。
2. Chrome が運営者に求めているとおり、Chrome のルートストアに含まれる別の階層のCAから新しいTLS証明書を取得します。
3. 新しい証明書は、サーバー証明書だけでなく、CAが提供する中間証明書を含むチェーン全体で導入します。
4. チェーンを提示しているサービス（Web サーバー、ロードバランサー、プロキシ、アプリケーション本体）をすべて再起動または再読み込みします。
5. サイトの確認コマンドをもう一度実行し、発行者が変わったことを確認します。独自の信頼データを持つホスト、コンテナ、ランタイムでは、プラットフォーム別の確認も繰り返してください。
6. ランタイムをまだ更新できない場合は、上の事実に挙げたベンダー自身の手順に従ってください。たとえば OpenJDK は、単体ランタイム向けの手順を公開しています。

関連するイベントページ

• CVE-2026-113470 (英語ページ)
• CVE-2026-115557 (英語ページ)
• CVE-2026-115570 (英語ページ)
• CVE-2026-111943 (英語ページ)