electron

both live server plug-ins are broken? (at least on ARM Macs) im in a webdev class and I can't stand using VSC, so I switched to pulsar. I tried jas-chen/atom-live-server and richiksc/atom-live-server-plus both live-server extensions work fine on my windows 11 laptop but I recently got a MacBook Air m5 and nether extension works. I get: Some installed packages could not be loaded because they contain native modules that were compiled for an earlier version of Pulsar. and fsevents@1.2.13 – Loading non-context-aware native module in renderer: '/Users/nova/.pulsar/packages/atom-live-server/node_modules/fsevents/build/Release/fse.node'. See https://github.com/electron/electron/issues/18397. I select 'rebuild extension' and pulsar says it was successful but i restart pulsar and the extension is still broken. pulsar is a few versions behind because i decline to update it, but i also downgraded the version on my mac and no luck...

@pranavgawai_ i also did the same for the organization "electron". Initially some good first issues: • fiddle#1687 • fiddle#1688 and then some meaningful contributions: • fiddle-core#138 • fiddle#1695 got good feedback from maintainers. t.co

eMudhra中間CA証明書の秘密鍵危殆化インシデント 概要 何が起きたか: 2026年10月、インドの認証局（CA）である eMudhra が発行した 8つの中間CA証明書（TLS用6つ、コード署名用2つ） において、秘密鍵 d が1バイト以下の整数で生成されており、公開された証明書から誰でも秘密鍵を算出・復元できる状態であったことが発覚した1516。 主な影響: パブリックトラストされた中間CAの秘密鍵が事実上公開された状態となったため、攻撃者は任意のドメインに対する偽のTLSサーバー証明書、TLSクライアント証明書、およびコード署名証明書を独力で偽造でき、通信の盗聴・改ざん（中間者攻撃：MitM）、パブリックCAを信頼するmTLS（クライアント証明書認証）の突破、不正バイナリへの署名が可能な状態となった。さらに、これら8つの中間CAはeMudhra自身のルートCA（emSign ECC Root CA - G3）だけでなく、Sectigo（旧Comodo）のルートCA（AAA Certificate Services）からもクロス署名されていたため、計8鍵ペア・16枚の中間CA証明書が影響を受けた1415。 対策: 主要Webブラウザ（Chrome、Firefox、Safari、Edge）には緊急のブロックリスト（CRLSet / OneCRL等）が自動配信済みである5111213。しかし、ブラウザ以外のCLIツール（curl、git）、Linuxの ca-certificates、コンテナイメージ、および独自のトラストストアを内蔵する言語ランタイム（Python certifi、Node.js、Go、Rust webpki-roots 等）・開発ツール（JetBrains IDE等）・Electron製アプリ（VS Code、Obsidian、Slack等）は自動保護されないため、システム管理者および開発者による個別のパッケージ更新・再ビルドが必須である1229。 ! 本記事は 2026年10月31日 時点の公式発表および一次情報に基づいている。最新のパッチ提供状況や緩和策については各ベンダーの公式アドバイザリを確認してほしい。 被害・影響範囲と各環境の対応状況 項目 公表されている内容 関連識別子 Mozilla Bugzilla Bug 2083449 5 / CVE-2026-111943（Go）26 / CVE-2026-113470（AWS）20 / CVE-2026-114406（Red Hat）19 / CVE-2026-115570（Electron）29 危殆化した中間CA eMudhraの中間CA 8鍵ペア・計16証明書（TLS用6鍵ペア、コード署名用2鍵ペア）14 親ルートCA ・emSign ECC Root CA - G3（配下の emSign Root TLS CA - G3 / emSign Root CS CA - G3 を含む）512 ・AAA Certificate Services（Sectigo / 旧Comodo によるクロス署名ルート）14 影響を受けた期間 2025年4月30日（鍵生成・証明書発行）〜 2026年10月17日（発覚・緊急遮断開始）5 eMudhraの事業対応 2026年10月21日、グローバルなパブリックSSL/TLS証明書事業からの撤退を表明5 1. 危殆化した8つの中間CA証明書と秘密鍵 d 今回危殆化が確認された8つの中間CA（P-384 / secp384r1）と、Cloudflareの解析レポート等で公表された実際の秘密鍵 d は以下の通りである。G3B シリーズはオランダ法人（O=eMudhra BV, C=NL）、G3C シリーズは米国法人（O=eMudhra Inc, C=US）名義で発行されており、TLS用の6つの中間CA（#1〜#6）の拡張鍵用途（X509v3 Extended Key Usage）には TLS Web Server Authentication（サーバー証明書）と TLS Web Client Authentication（クライアント証明書）の両方が含まれている1416。 # 中間CA名 (Common Name) 用途 (EKU) 発行対象 秘密鍵 d SPKI SHA-256 ハッシュ 1 EM DV TLS CA - G3B TLS サーバー / クライアント (DV) eMudhra BV (NL) 156 (0x9c) EBED6475C2C2D80FCB...6F5B5105 2 EM DV TLS CA - G3C TLS サーバー / クライアント (DV) eMudhra Inc (US) 230 (0xe6) 49DD353DC2B919A377...A434FE5F 3 EM OV TLS CA - G3B TLS サーバー / クライアント (OV) eMudhra BV (NL) 155 (0x9b) 43BFFA19D6EF651451...6DE2717B 4 EM OV TLS CA - G3C TLS サーバー / クライアント (OV) eMudhra Inc (US) 4 (0x04) 63ECEFEE431D49523B...6C109CF8 5 EM EV TLS CA - G3B TLS サーバー / クライアント (EV) eMudhra BV (NL) 115 (0x73) E0254C7FCDC265E2F0...7D5A8A41 6 EM EV TLS CA - G3C TLS サーバー / クライアント (EV) eMudhra Inc (US) 56 (0x38) 5C0660A2B164910D8F...811F81A0 7 EM OV CS CA - G3B Code Signing eMudhra BV (NL) 66 (0x42) EC4FFA1AD0AC880813...5EB4F6B6 8 EM OV CS CA - G3C Code Signing eMudhra Inc (US) 237 (0xed) 92C063D67E8F14DB71...D25E0E30 全16証明書（eMudhra発行版8枚＋Sectigoクロス署名版8枚）および親ルートCAの完全なSHA-256ハッシュ一覧【親ルートCA（計4証明書）】 - emSign ECC Root CA - G3 (eMudhra最上位ECCルート) SHA-256: 86A1ECBA089C4A8D3BBE2734C612BA341D813E043CF9E8A862CD5C57A36BBE6B - AAA Certificate Services (Sectigo / 旧Comodo クロス署名元ルート) SHA-256: D7A7A0FB5D7E2731D771E9484EBCDEF71D5F0C3E0A2948782BC83EE0EA699EF4 - emSign Root TLS CA - G3 (emSign ECC Root CA - G3 配下) SHA-256: 7DD78D5F4F13459A83DFF9ABBBA62EDBAF6F2D102BF257FD712F4D9F2746ED8D - emSign Root CS CA - G3 (emSign ECC Root CA - G3 配下) SHA-256: F2EDAAFF3D9B701FB4D14C9F285F8C0BAD90FC3BCC1FA07D47F4718EDABA34A5 【危殆化した中間CA（計8鍵ペア・16証明書）】 1. EM DV TLS CA - G3B (d = 156) - SPKI SHA-256 : EBED6475C2C2D80FCB199F3FE8DD6E6B3CE60B77EB15D4E42C3DEC0C6F5B5105 - eMudhra発行版 : 42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493 - Sectigo署名版 : 45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE 2. EM DV TLS CA - G3C (d = 230) - SPKI SHA-256 : 49DD353DC2B919A3770645117D0E60C16115E7D1BC259EEFE734B00EA434FE5F - eMudhra発行版 : 0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19 - Sectigo署名版 : 62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72 3. EM OV TLS CA - G3B (d = 155) - SPKI SHA-256 : 43BFFA19D6EF651451F6841E019931E96F6F2EAEFF28AB4B6F1CE4576DE2717B - eMudhra発行版 : 98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B - Sectigo署名版 : 5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699 4. EM OV TLS CA - G3C (d = 4) - SPKI SHA-256 : 63ECEFEE431D49523BC1136C4E72D0206A477086CAF606CD5CF025686C109CF8 - eMudhra発行版 : CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F - Sectigo署名版 : 7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489 5. EM EV TLS CA - G3B (d = 115) - SPKI SHA-256 : E0254C7FCDC265E2F0F8A428DABB75AB4AE039B4872D62F5EE57F0877D5A8A41 - eMudhra発行版 : E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838 - Sectigo署名版 : 579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512 6. EM EV TLS CA - G3C (d = 56) - SPKI SHA-256 : 5C0660A2B164910D8FF589C18E14552E9E0EC237DCEFE2CB736D41A4811F81A0 - eMudhra発行版 : 432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3 - Sectigo署名版 : FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F 7. EM OV CS CA - G3B (d = 66) - SPKI SHA-256 : EC4FFA1AD0AC88081314B7AAFFEF6A91F97CD57291BB5BA686C5415F5EB4F6B6 - eMudhra発行版 : 9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4 - Sectigo署名版 : A496E23AC0CAB8155FC9B117B97EAE368EFCBB9041AEC8804D5A308D2D01C2D8 8. EM OV CS CA - G3C (d = 237) - SPKI SHA-256 : 92C063D67E8F14DB71D288E11266FFDAF69CBF115F7BAB14F3BC2F68D25E0E30 - eMudhra発行版 : 4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1 - Sectigo署名版 : 84112972B8E59D14560AE7E7119654474AAD119990CF3722BFC1E3B91615E1FD 2. Webブラウザ・OS・NSSの対応状況 対象 修正版 補足 Google Chrome / Chromium 自動適用済 2026-10-17にCRLSetで8鍵のSPKIハッシュを遮断。10月27日にChrome Root Store（v43）から emSign ECC Root CA - G3 を削除11 Mozilla Firefox 158.0.1 / ESR 153.5.1 / 115.43.1 2026-10-17にOneCRL（Bug 2083382）で自動遮断。Remote Settings無効環境向けに10月20日に修正版をリリース56 Mozilla NSS 3.131.1 emSign ECC Root CA - G3、emSign Root CA - C1、emSign ECC Root CA - C3 を削除（Bug 2084101 / Bug 2083709）7810 Apple Safari / macOS / iOS 自動適用済 / CLIは 準備中 Safari等のネイティブフレームワーク利用アプリは10月19日のセキュリティ設定更新で保護済み。ただしmacOS付属の git / curl / python3 等は静的な /etc/ssl/cert.pem を参照するため手動削除が必要（HT2149555）212 Microsoft Edge / Windows KB5134133 10月20日にWindows Disallowed CTLおよびEdge CRLSetで自動遮断。閉域網向けに10月26日に定例外更新 KB5134133 を配信1314 Android 自動適用済 Google Play開発者サービスおよびChrome Root Storeアップデートにより遮断済み11 3. 主要Linuxディストリビューションの対応状況 Linux環境では ca-certificates パッケージおよび nss パッケージの更新が必要である（コンテナ環境ではベースイメージの再ビルドも必須）1。 ディストリビューション 対象リリース / パッケージ 修正版 補足 Ubuntu Ubuntu 26.10 / 26.04 LTS / 24.04 LTS / 22.04 LTS (ca-certificates) 20260816ubuntu0.26.10.1 / 0.26.04.1 / 0.24.04.1 / 0.22.04.1 アドバイザリ: USN-8944-117 Debian Debian 13 Trixie / Debian 12 Bookworm (ca-certificates) 20250419+deb13u1 / 20250419~deb12u2 アドバイザリ: DSA-6572-1（emSign ECC Root CA - G3 と Comodo AAA Services root の両方を削除）18 RHEL (Red Hat) RHEL 8, RHEL 9, RHEL 10, RHEL 7 ELS (ca-certificates) 2026.2.92_v9.0.319-90.3.el9_8 等1 アドバイザリ: RHSB-2026-012 / CVE-2026-114406（RHEL 8は -81.3.el8_10、RHEL 10は -100.3.el10_2）19 Amazon Linux AL2023 / AL2 (ca-certificates) 2025.2.76-1.0.amzn2023.0.4 / 2025.2.76-1.amzn2.0.31 アドバイザリ: ALAS2023-2026-3306 / CVE-2026-113470（パッケージリポジトリリリースは 2023.12.20261026）20 Alpine Linux Edge / v3.20以降 (ca-certificates) 20261020-r0 コンテナベースイメージで多用されるため apk upgrade と再ビルドが必要1 4. 主要クラウド（AWS / Azure / GCP）の対応状況 クラウド 対象サービス / OS 修正版 補足 AWS 共有トラストストア / CloudFront / EC2 / Python SDK (botocore) 適用済 / botocore 1.43.117 アドバイザリ: 2026-150-AWS。マネージドサービス側は2026-10-21に適用済み。EC2上のOSパッケージおよび botocore / boto3 の更新が必要21 Microsoft Azure Azure マネージド基盤 / Azure VM 適用済 / KB5134133 マネージド基盤および自動CTL更新有効VMは適用済み。閉域網VM等は KB5134133 またはLinux ca-certificates の適用が必要1314 Google Cloud (GCP) マネージド基盤 / GCE / GKE (COS) / gcloud CLI 適用済（COS / gcloud は要更新） アドバイザリ: GCP-2026-071。GKE / GCEのContainer-Optimized OSはノード更新または緩和スクリプト cos_ca_cert_mitigation の実行、gcloud CLIは最新版への更新が必要22 5. 言語ランタイム・パッケージマネージャ・開発ツールの対応状況 ソフトウェア 対象パッケージ / コンポーネント 修正版 補足 Python (CPython) Python 3.11〜3.15 3.15.2 / 3.14.10 / 3.13.18 / 3.12.16 / 3.11.18 Windows / macOS 公式インストーラ同梱の証明書バンドル等を更新1 Python (certifi) certifi 2026.10.19 GHSA-6q48-6c7w-9gw2。同梱CAバンドルから該当ルートを削除23 Python (pip / uv) pip / Astral uv pip 26.2.21 / uv 0.13.524 pip は certifi、uv は webpki-roots を内部に同梱（uv は 0.13.4 以降で修正24、pip は 26.2.2 で更新1）。UV_SYSTEM_CERTS=1 でOSストア参照への切り替えも可能 Node.js Node.js 22.x / 24.x / 26.x 26.12.1 / 24.22.1 / 22.23.425 コンパイル時にMozilla NSSのルートストアを内蔵（NSS 3.131.1を取り込んだ修正版）。起動オプション --use-openssl-ca / --use-system-ca によるOS証明書ストア参照も可能 Bun / Deno Bun / Deno Bun 1.4.4 / Deno 2.9.8 内蔵CAバンドルから該当ルートを削除1 Go (golang) 標準ライブラリ crypto/x509 1.27.3 / 1.26.10 CVE-2026-111943（Issue #82345）。crypto/x509 内に8鍵のSPKIブロックリストを直接実装。バイナリの再ビルドが必要26 Rust (rustls / rustup) webpki-roots / rustls-webpki / rustup 1.0.10 / 0.103.1627 / rustup 1.29.21 静的にルート証明書を埋め込むクレート。依存関係の更新とバイナリの再コンパイルが必要27 Java (Oracle JDK / JBR) Oracle JDK / JetBrains Runtime Oracle JDK 25.0.5.0.3 / 21.0.13.0.3 / 17.0.21.0.3 等 OpenJDKはディストリビューションの ca-certificates-java 更新と /etc/ssl/certs/java/cacerts の再生成が必要1 JetBrains製品 JetBrains IDEs / Toolbox App IDE 2026.3 等 / Toolbox 3.9.1 / 3.8.2 独自のJava Runtime（JBR）とトラストストアを同梱するため、各IDE（2025.3〜2026.3 の各最新マイナー更新）およびToolbox Appの更新が必須28 Docker / Git / Claude Code Docker Desktop / Git for Windows / GitHub CLI / Claude Code Docker 4.96.2 / Git 2.56.0.3 / gh 2.102.1 / Claude Code 2.1.303 各ツールが内包するCAバンドルまたはランタイムを更新1 Cloudflare cloudflared / WARP Client 2026-10-20以降の最新版 Cloudflareエッジは対策済み。クライアント側のWARPおよび cloudflared の更新が必要15 6. Electronフレームワークおよび主要Electron製アプリの対応状況 ElectronはChromiumとNode.jsの両方のネットワークスタックおよび証明書ストアを独自に内包しており、OSやブラウザを更新してもElectron製デスクトップアプリは保護されない（CVE-2026-115570 / GHSA-jr5w-w6x2-84p9）129。各アプリケーションが修正版Electron（44.9.1 / 43.8.1 / 42.11.16 以降）を取り込んでビルドしたバージョンへ更新する必要がある。 アプリケーション / フレームワーク 修正版 補足 Electron（フレームワーク本体） 45.0.0-beta.6 / 44.9.1 / 43.8.1 / 42.11.16 CVE-2026-115570（GHSA-jr5w-w6x2-84p9）。Chromiumのネットワーク層およびNode.jsの tls / https / fetch モジュールの双方で危殆化した中間CAをブロック29 Visual Studio Code 1.143.1 上流のElectron公式修正版（43.8.1）へバージョンを上げるのではなく、Microsoft独自のカスタムElectron 43.7.7 にパッチをバックポートしたビルド（ElectronBuildId: 15743441） を適用して対策を実施（1.143.1 ではRemote用Node.jsも 24.22.1 へ更新）13032 Obsidian (Desktop) 1.14.51 内蔵Electronを 43.7.5 から修正済みの 43.8.3 へ更新。アプリ内の自動更新機能だけではElectron本体が更新されないため、公式サイトから最新インストーラを再ダウンロードして上書きインストールが必要31 Slack (Desktop) 4.52.182 macOS / Windows 向けに、内蔵するElectron Frameworkを修正済みの 44.9.1 へ更新1 Discord / その他のElectron製アプリ 各アプリの最新版 emudhra.we-have-a-problem.com でも注意喚起されている通り、修正版Electron（44.9.1 / 43.8.1 / 42.11.16 以降）を採用したビルドへの更新が必要1 なお、macOS環境にインストールされている一般的なElectron製アプリ（SlackやObsidian等）が修正済みのElectronバージョン（44.9.1 / 43.8.1 / 42.11.16 以降）を取り込んでいるかどうかは、アプリバンドル内の Electron Framework.framework/Resources/Info.plist の CFBundleVersion で確認できる。 ただし、Visual Studio Code はカスタムビルドの Electron 43.7.7（ms_build_id="15743441"）に独自パッチを当てて対応しているため、修正済みの VS Code 1.143.1 であっても Electron Framework.framework の CFBundleVersion は 43.7.7 のまま変化しない。そのため、VS CodeについてはElectronのバージョン番号ではなく、VS Code本体のバージョン（1.143.1 以降）または「Visual Studio Code について（About）」に表示される ElectronBuildId: 15743441 を確認する必要がある3032。 一般的なElectron製アプリ（Slack等）が内包するElectronバージョンの確認例（44.9.1 / 43.8.1 / 42.11.16 以降であれば対策済） defaults read "/Applications/Slack.app/Contents/Frameworks/Electron Framework.framework/Resources/Info.plist" CFBundleVersion VS Codeは独自パッチ版 Electron (43.7.7 / ElectronBuildId: 15743441) を使用しているため、アプリ本体のバージョン (1.143.1以降) を確認する defaults read "/Applications/Visual Studio Code.app/Contents/Info.plist" CFBundleShortVersionString 影響を受ける条件 本インシデントの影響は、危殆化した中間CAの親ルート（emSign ECC Root CA - G3 またはクロス署名元の AAA Certificate Services）を信頼し、かつ失効確認やブロックリストが機能しないソフトウェアを使用している環境で発生する。具体的には、証明書の用途に応じて以下の条件に該当する場合に影響を受ける。 1. TLSクライアント通信（サーバー証明書の検証）を行う環境 TLSにおける証明書失効確認（CRLおよびOCSP）は、プライバシーや可用性（Soft-fail挙動）の観点から、多くのクライアント実装でデフォルト無効またはバイパス可能となっている。また、多くの非ブラウザクライアントはCertificate Transparency（CT）の強制チェックも行わない115。 未更新の非ブラウザソフトウェアを使用している場合（影響あり）: OpenSSL、GnuTLS、Go、Rust（rustls）、Python、Node.js、Electronなどを用いるバックエンドのAPI通信やCLIツール（curl、git、wget 等）は、ブラウザのような中央集権型の失効リストを持たず、かつデフォルトでOCSP/CRLチェックやCT検証を行わない。そのため、参照しているルート証明書ストア（CAバンドル）から親ルートCAを削除するか、TLSライブラリ自体に中間CAのブロックリストを組み込まない限り、危殆化した中間CAから偽造されたサーバー証明書を常に「有効」として受け入れてしまう126。 なお、この状態から実際に通信の盗聴・改ざん（中間者攻撃：MitM）が成立するには、攻撃者がクライアントと接続先サーバーの通信経路上（同一ネットワーク内でのARPスプーフィング、不正Wi-Fiアクセスポイント、BGPハイジャック、DNSキャッシュポイズニング／改ざん等）に介在できることが前提条件となる。 主要Webブラウザを使用している場合（自動保護済み）: Google Chrome（CRLSet）、Mozilla Firefox（OneCRL / CRLite）、Microsoft Edge、Apple Safariは、CAが発行するCRL/OCSPとは独立して、ブラウザベンダー自身が失効リスト（SPKIハッシュや発行者・シリアル番号のブロックリスト）を全端末へプッシュ配信する仕組みを備えているため、発覚当日に保護が完了している511。 2. クライアント証明書認証（mTLS）でパブリックCAバンドルを信頼しているサーバー環境 TLS用の6つの中間CA証明書には、拡張鍵用途（EKU）としてサーバー認証（TLS Web Server Authentication）だけでなく クライアント認証（TLS Web Client Authentication） も付与されている4。 通常、mTLS（相互TLS認証）では自社専用のプライベートCAのみを信頼する設定とするのが一般的だが、もしWebサーバーやAPIゲートウェイのクライアント証明書検証用ストアに未更新のパブリックCAバンドル（/etc/ssl/certs/ca-certificates.crt 等）を指定している場合、攻撃者は通信経路上に介在することなく、危殆化した中間CAの秘密鍵で任意のSubject / SANを持つクライアント証明書を偽造して直接提示するだけでクライアント認証を突破できる。 3. コード署名証明書を検証する環境 危殆化した8つの中間CAのうち2つ（EM OV CS CA - G3B / G3C）はコード署名（Code Signing）用途である14。インターネットから隔離された閉域網などで失効リスト（Windows Disallowed CTL等）が反映されていない環境において、攻撃者がこれらの中間CAで署名した不正バイナリやインストーラを検証・実行する場合に影響を受ける1314。 インシデントの時系列（タイムライン） Mozilla Bugzilla（Bug 2083449 / Bug 1970728）および各ベンダーの公式発表から判明している時系列は以下の通りである59。 日時 (UTC) 出来事 2025/04/30 eMudhraがHSMキーセレモニーを実施。KGCスクリプトのラップ/アンラップ・再インポート処理の欠陥により、8つの中間CA証明書（P-384）が 1 \le d \le 255 の秘密鍵で生成・署名される5。 2025/05/14 Sectigo（AAA Certificate Services）が8つの中間CAすべてに対してクロス署名を実施し、計16枚の中間CA証明書が有効化される45。 2025/05/23 該当中間CAが発行したCRL（証明書失効リスト）のECDSA署名が公開鍵と一致しない問題が発覚し、Mozilla Bugzilla Bug 1970728 が起票される9。 2025/06/06 eMudhraがCRLを証明書側の脆弱な鍵で再署名して不一致を解消したことで、秘密鍵の脆弱性が見逃されたまま Bug 1970728 がクローズされる59。 2026/10/17 18:05 セキュリティ研究者 Wayne がChrome Root Program等へ脆弱性を報告。8つすべての秘密鍵を復元した証拠として、各秘密鍵で "We have a problem here - Wayne." に署名したデータを提出15。 2026/10/17 19:45 Google Chrome が CRLSet 更新を配信し、8つのSPKI SHA-256ハッシュ（全16証明書）を遮断511。 2026/10/17 20:06 Mozillaが転送された報告を受領。独自に8つすべての秘密鍵が復元可能であることを確認し、22:59 UTCに Firefox OneCRL（Bug 2083382）の配信を完了56。 2026/10/18 Mozilla Bugzilla Bug 2083449 が起票される。eMudhraおよびSectigoが該当する中間CA証明書を caCompromise 理由で失効（Revoke）5。 2026/10/19 Apple がmacOS / iOS向けに自動セキュリティ設定アップデートによる中間CA遮断を開始12。 2026/10/20 Bug 2083449の一般公開。Mozilla NSS 3.131.1 および Firefox 158.0.1、Microsoft Disallowed CTL配信、Cloudflare 第1報公開、検証サイト emudhra.we-have-a-problem.com、Electron（44.9.1 等）、Python certifi 2026.10.19、Debian DSA-6572-1 等が公開15101315182329。 2026/10/21 eMudhra がインシデント調査報告を公表するとともに、グローバルなパブリックSSL/TLS証明書事業からの撤退を正式表明5。同日、Node.jsセキュリティリリースおよびAWSアドバイザリ（2026-150-AWS）が公開2125。 2026/10/26 Microsoft がWindows定例外（OOB）更新プログラム KB5134133 をリリース14。 2026/10/27 Google Chrome が Chrome Root Store から emSign ECC Root CA - G3 を完全削除11。 2026/10/28 emudhra.we-have-a-problem.com/apple.html が公開され、macOS付属の git / curl / python3 が /etc/ssl/cert.pem の影響で依然脆弱であり、OS更新によって手動緩和策が上書きされた問題が公表される2。 2026/10/29 Apple がサポート文書（149555）を公開・更新し、CLIツール向けに /etc/ssl/cert.pem から該当ルートCAを手動削除する公式手順を案内12。 2026/10/30 Cloudflare が第2報ブログを公開し、8つの秘密鍵 d の具体的な値（4, 56, 66, 115, 155, 156, 230, 237）とインターネット上のパッチ適用率・悪用観測データを発表16。 技術的な仕組みと原因の分析 1. 「384ビット」のはずが「1バイト（d < 256）」だった秘密鍵 問題となった8つの中間CA証明書は、いずれもNIST標準の楕円曲線 P-384（secp384r1） を使用していた。 楕円曲線暗号（ECC）において、曲線のベースポイント（生成元）を G、位数を n（P-384では約 3.94 \times 10^{115}、384ビット＝48バイトの素数）とすると、秘密鍵 d は区間 [1, n-1] から一様ランダムに選ばれた整数であり、対応する公開鍵 Q は曲線上のスカラー倍算によって以下のように計算される15。 Q = d \cdot G = \underbrace{G + G + \dots + G}_{d\text{ 回}} 通常、384ビットの乱数で生成された秘密鍵 d を公開鍵 Q から逆算すること（楕円曲線離散対数問題：ECDLP）は、現代の計算機では事実上不可能である。しかし、今回eMudhraの中間CAに設定されていた秘密鍵 d を48バイト（ビッグエンディアン）のバイト列として表現すると、上位47バイトがすべて 0x00 であり、最下位の1バイト（8ビット）のみに非ゼロの値が入っている状態（すなわち 1 \le d \le 255） であった。 たとえば EM OV TLS CA - G3C の秘密鍵は d = 4 であり、公開鍵 Q はベースポイント G を4回足し合わせた Q = 4G であった。そのため、公開された証明書から公開鍵 Q を取り出し、1G, 2G, 3G, \dots, 255G を順番に計算して Q と一致するかを調べることで、一般的なPCでも 1ミリ秒未満（最大255回のループ）で8つすべての秘密鍵を特定できる状態 になっていた516。 暗号学的証拠（Proof of Key Control）の検証方法 発見者のWayne氏は、復元した8つの秘密鍵を用いて "We have a problem here - Wayne." というテキスト（message.txt）に対するECDSA署名を作成し、証拠として提出した。公開リポジトリ（proof.zip）に含まれるファイルを用い、openssl コマンドで公開証明書の公開鍵と完全一致すること、および署名が数学的に正当であることを以下のように確認できる14。 1. 中間CA証明書から抽出した公開鍵と、署名検証用の公開鍵が完全に一致することを確認 openssl x509 -in EM-DV-TLS-CA-G3B.crt.pem -noout -pubkey | diff - EM-DV-TLS-CA-G3B.pub.pem 2. 公開された中間CAの公開鍵で、Wayne氏の署名 (EM-DV-TLS-CA-G3B.sig) が検証成功することを確認 openssl dgst -sha384 -verify EM-DV-TLS-CA-G3B.pub.pem -signature EM-DV-TLS-CA-G3B.sig message.txt 出力: Verified OK 2. なぜ1バイトの鍵が生成・署名されたのか（2025年4月30日のHSMキーセレモニー） パブリック認証局がルートCAや中間CAの鍵ペアを生成する際は、通常、物理的に隔離されたセキュアルーム内で複数の鍵管理者・立会人・監査人の監視およびビデオ記録のもと、事前承認された手順書に従ってHSMを操作する キーセレモニー（Key Generation Ceremony） が実施される。 eMudhraがMozilla Bugzilla（Bug 2083449のComment #10・#11およびComment #62の添付文書 eMudhra_Response_to_Google.pdf）に提出した説明によると、今回危殆化した鍵はHSM（Hardware Security Module）自体の故障ではなく、2025年4月30日に実施されたキーセレモニーにおける鍵生成スクリプト（KGCスクリプト）の欠陥と、再インポートされた脆弱な鍵オブジェクトからCSRを生成してしまったことが連鎖した結果とされている5。 KGCスクリプトにおけるラップ／アンラップ（Wrap/Unwrap）処理の欠陥: eMudhraは2025年4月30日、FIPS 140-2 Level 3準拠のUtimaco製HSMを使用して計24個の中間CAを生成した（Comment #5, #10, #11）。このうち米国（G3C）および欧州（G3B）向けの8つのP-384中間CAについては、データ主権要件に対応するため米国・欧州データセンターへ鍵をエクスポートする用途であったことから、通常のキーセレモニー手順から逸脱（approved deviation）し、KGCスクリプト内で鍵のラップ／アンラップおよび再インポート（wrap/unwrap and re-import）のリハーサル処理を導入していた（Comment #11, #62）。 eMudhraの説明によれば、最初の正規のECC鍵ペア自体はHSM上で正常に生成されたものの、このスクリプトのコード欠陥により、ラップ／アンラップを経てHSM上に作られた2つ目の（再インポートされた）鍵オブジェクトが脆弱な鍵（上位47バイトがゼロで d < 256）となり、同一または類似したラベルでHSM内に存在する状態になったとされる5。 再インポートされた脆弱な鍵オブジェクトからのCSR生成: 続く証明書署名要求（CSR）の作成工程において、本来の1つ目の鍵ではなく、2つ目の（再インポートされた）脆弱な鍵オブジェクトを使ってCSRが生成された（Comment #11では「ラベルが似ていたため誤って使用された」、Comment #62のGoogle向け回答書では「スクリプトが再インポート側の鍵からCSRを生成する指定になっていた」と説明されている）。このCSRに対してeMudhra自身のG3ルートCAが署名を行い、さらにSectigoの AAA Certificate Services にも同じCSRが送られてクロス署名されたことで、脆弱な公開鍵を持つ16枚の中間CA証明書が成立した。 なお、「ラップ／アンラップおよび再インポートの過程で、具体的にスクリプトやHSMのどの処理・パラメータによって48バイト中先頭47バイトがゼロ（d < 256）という鍵データに劣化したのか」というコードレベルのメカニズムについては、MozillaやChrome Root Program、コミュニティ研究者からスクリプト全文の開示と技術的説明が求められているものの、本稿執筆時点ではeMudhraからまだ開示されていない（Comment #30, #33, #65, #66）45。 2025年5〜6月の「CRL署名不一致（Bug 1970728）」における対応: 証明書発行直後の2025年5月23日、これらの中間CA（TLS用の6つ）が発行したCRL（証明書失効リスト）の署名が中間CA証明書の公開鍵で検証できないという問題が外部から指摘され、Mozilla Bugzilla Bug 1970728 として起票されていた（Comment #5）。 eMudhraの回答（Comment #11）によると、当時CRLは最初に生成された本来の強い秘密鍵で署名されていたため、脆弱な鍵の公開鍵を持つ中間CA証明書との間で署名不一致が発生していた。しかし当時のeMudhraは鍵自体の脆弱性に気づかず、CRLを脆弱な鍵（d < 256）側で再署名することで不一致を解消し、2025年6月6日にBug 1970728をクローズしていた。この対応により鍵の脆弱性が検知されないまま、約1年5ヶ月にわたり問題が継続することとなった59。 3. 攻撃成立の仕組み（未更新のCLI・ランタイムに対する中間者攻撃） 攻撃者が復元した中間CA秘密鍵（例：EM DV TLS CA - G3B の d = 156）を悪用した場合、攻撃が失敗（遮断）する主要Webブラウザ環境（緑枠） と、攻撃が成功（中間者攻撃が成立）してしまう未更新のCLI・ランタイム環境（赤枠） で挙動がどのように分かれるかを図解する12。 4. 対応が複雑化している原因（Sectigoクロス署名による二重チェーンと独自CAバンドル） 本インシデントへの対処が単純なルートCAの1件削除やOS更新だけで完結せず、広範な対応を要する原因は以下の2点にある。 Sectigo（旧Comodo）AAA Certificate Services によるクロス署名（二重チェーン構造）: 危殆化した8つの中間CA秘密鍵（SPKI）に対しては、eMudhra自身のG3ルート階層（emSign ECC Root CA - G3）から発行された8枚の証明書だけでなく、レガシー環境との互換性を確保するために SectigoのルートCA AAA Certificate Services から直接署名された8枚のクロス署名証明書 が存在する14。 そのため、クライアント側で中間CA自体（またはSPKI）を個別にブロックする機構がない環境（OpenSSLの /etc/ssl/certs 等）では、emSign ECC Root CA - G3 だけを削除しても、トラストストア内に AAA Certificate Services が残っていれば、クロス署名側の中間CA証明書を使ったチェーンによって検証を通過してしまう。実際にDebianの DSA-6572-1 やAppleの緩和手順では、emSign ECC Root CA - G3 と AAA Certificate Services（Comodo AAA Services root）の両方を削除する措置が取られている1218。 OSとは独立した静的CAバンドル（macOS /etc/ssl/cert.pem・言語ランタイム・Electron）: macOSの /etc/ssl/cert.pem: Appleは10月19日にmacOSのシステムキーチェーン（Security.framework）向けにブロックリストを配信したが、macOSに標準付属する /usr/bin/git、/usr/bin/curl、/usr/bin/python3、ruby、perl、openssl（Xcode Command Line Toolsを含む）はシステムキーチェーンではなく、ディスク上の静的ファイル /etc/ssl/cert.pem を参照して証明書検証を行う仕様になっていた。このファイルはバックグラウンド更新では書き換わらないうえ、10月26日にリリースされたmacOSアップデートでも未修正のまま上書きされたため、手動で /etc/ssl/cert.pem を編集しない限り、git clone 等が影響を受ける状態が残る212。 言語ランタイム・Electronの静的バンドル: Pythonの certifi、Node.js（内蔵NSSデータ）、Rustの webpki-roots、Electron、Javaの cacerts などは、OSの ca-certificates を更新しても自動的に更新されないため、アプリケーションやライブラリの個別アップデートが必須となる12325。 対策と緩和策 1. 自環境の影響確認コマンド（emudhra.we-have-a-problem.com 検証エンドポイント） MozillaのDennis Jackson氏らが運営する情報集約・検証サイト emudhra.we-have-a-problem.com（日本語版ページも公開されている）では、実際に危殆化した中間CA（EM DV TLS CA - G3B）の秘密鍵を用いて署名したテスト用エンドポイントが公開されている。対策の適用前後において以下のコマンドを実行し、TLSハンドシェイクが失敗（証明書エラー）すれば対策済み（安全）、接続が成功（HTTP 200等）すれば未対策 と判別できる123。 1. curl の確認（eMudhraネイティブルート経由 / Sectigo AAA クロス署名ルート経由 / CT未記録チェーンをテスト） → すべて「curl: (60) SSL certificate problem」（HTTP 000）となれば安全。「HTTP 200」が表示された場合は未対策 curl -sS -o /dev/null -w "HTTP %{http_code}\n" dv-g3b-emudhra.we-have-a-problem.com curl -sS -o /dev/null -w "HTTP %{http_code}\n" dv-g3b-aaa-emudhra.we-have-a-problem.com curl -sS -o /dev/null -w "HTTP %{http_code}\n" dv-g3b-noct-emudhra.we-have-a-problem.com curl -sS -o /dev/null -w "HTTP %{http_code}\n" dv-g3b-aaa-noct-emudhra.we-have-a-problem.com 2. git の確認 → 「fatal: unable to access ... SSL certificate problem」になれば安全。コミットハッシュが表示された場合は未対策 git ls-remote git-emudhra.we-have-a-problem.com 3. Python (標準ライブラリ urllib および requests/certifi) の確認 → SSLError (CERTIFICATE_VERIFY_FAILED) が発生すれば安全。「VULNERABLE」と出力された場合は未対策 python3 -c "import urllib.request; urllib.request.urlopen('dv-g3b-emudhra.we-have-a-problem.com'); print('VULNERABLE')" python3 -c "import requests; requests.get('dv-g3b-emudhra.we-have-a-problem.com'); print('VULNERABLE')" 4. Node.js の確認 → 「SAFE」と出力されれば安全。「VULNERABLE 200」と出力された場合は未対策 node -e "fetch('dv-g3b-emudhra.we-have-a-problem.com').then(r => console.log('VULNERABLE', r.status)).catch(e => console.log('SAFE', e.cause?.code || e.message))" 2. Linuxサーバー・コンテナイメージの更新 Linuxディストリビューションのパッケージマネージャを通じて ca-certificates（および nss）を最新バージョンへアップデートする。DockerやKubernetes等のコンテナ環境では、ホストOSだけでなく すべてのコンテナイメージを再ビルド・再デプロイする必要がある1。 Ubuntu / Debian 系 sudo apt update && sudo apt install --only-upgrade -y ca-certificates libnss3 sudo update-ca-certificates --fresh Ubuntu / Debian 系で OpenJDK (ca-certificates-java) を使用している場合は cacerts の再生成も実行 sudo rm -f /etc/ssl/certs/java/cacerts && sudo update-ca-certificates --fresh RHEL / AlmaLinux / Rocky Linux / Amazon Linux 2023 系 sudo dnf upgrade --refresh -y ca-certificates nss sudo update-ca-trust Alpine Linux (Dockerfile 等) apk update && apk upgrade ca-certificates 3. macOS における /etc/ssl/cert.pem の公式手動緩和策（Apple 149555） macOSではシステムの自動セキュリティ更新が適用されていても、macOSまたはXcode Command Line Toolsに付属する curl、git、python3、ruby、perl、openssl などのCLIツールは /etc/ssl/cert.pem を参照するため、将来のmacOSアップデートで同ファイルが修正されるまで影響を受け続ける。Appleは公式サポート文書（149555）にて、以下の4ステップで /etc/ssl/cert.pem から emSign ECC Root CA - G3 および AAA Certificate Services を削除する手順を案内している12。 1. バックアップの作成（すでに .orig が存在する場合は保持） [ -e /etc/ssl/cert.pem.orig ] || sudo cp -p /etc/ssl/cert.pem /etc/ssl/cert.pem.orig 2. emSign ECC Root CA - G3 の削除（成功時は何も出力されない） t=$(mktemp) && awk -v s='=== /C=IN/OU=emSign PKI/O=eMudhra Technologies Limited/CN=emSign ECC Root CA - G3' '/^(===|###) /{skip=0} $0==s{skip=1} !skip' /etc/ssl/cert.pem > "$t" && [ -s "$t" ] && sudo install -m 0644 -o root -g wheel "$t" /etc/ssl/cert.pem; rm -f "$t" 3. Sectigo クロス署名チェーンも遮断するため AAA Certificate Services も削除（成功時は何も出力されない） t=$(mktemp) && awk -v s='=== /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services' '/^(===|###) /{skip=0} $0==s{skip=1} !skip' /etc/ssl/cert.pem > "$t" && [ -s "$t" ] && sudo install -m 0644 -o root -g wheel "$t" /etc/ssl/cert.pem; rm -f "$t" 4. 削除結果の確認（両方とも削除されていれば何も出力されない） openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services' ! macOSアップデート時の注意点: Appleの公式案内にある通り、恒久修正を含まないmacOSのソフトウェアアップデートを適用すると、/etc/ssl/cert.pem がAppleの元のファイルで上書きされ、緩和策が元に戻ってしまう場合がある。OSアップデート後には必ず上記ステップ4の確認コマンドを実行し、もし証明書が再出現していた場合は sudo rm /etc/ssl/cert.pem.orig で古いバックアップを削除した上で再度ステップ1〜4を実行する必要がある212。 また、macOS標準付属の /usr/bin/pip3（およびそこから作成された仮想環境の pip）は独自の古い証明書バンドルを内部に保持しているため、上記で修正した /etc/ssl/cert.pem を参照させるには以下の設定を追加する1。 macOS標準の python3 / pip3 に修正済みの /etc/ssl/cert.pem を参照させる設定 F="$(/usr/bin/python3 -c 'import sysconfig; print(sysconfig.get_path("stdlib"))')/sitecustomize.py" && echo 'import os; os.environ.setdefault("PIP_CERT", "/etc/ssl/cert.pem")' | sudo tee -a "$F" > /dev/null && sudo chmod 644 "$F" 4. 言語ランタイム・開発ツール・Electronアプリのアップデートと緩和策 Python (certifi / pip / uv / botocore): すべての仮想環境（venv）、Poetry / Pipenv / uv のロックファイル、およびCI/CD環境内の certifi を 2026.10.19 以降へ更新する23。pip install --upgrade "pip>=26.2.2" "certifi>=2026.10.19" "botocore>=1.43.117" また、Astral uv を利用している場合は 0.13.5（0.13.4 以降）へ更新する24。環境変数 UV_SYSTEM_CERTS=1 を設定して更新済みのOSトラストストアを参照させる回避策も有効である。 Node.js / Electron: Node.jsは修正版（26.12.1、24.22.1、**22.23.4）へ更新する25。直ちにランタイム自体の更新が難しい場合は、OS側の ca-certificates を更新した上で、起動オプション --use-openssl-ca または --use-system-ca（環境変数 NODE_OPTIONS="--use-openssl-ca"）を指定することでOSの証明書ストアを使用できる。また、VS Code（1.143.1）30、Obsidian（1.14.5、要最新インストーラ再実行）31、Slack等のElectron製アプリは各ベンダーの修正版へ更新する29。 Go / Rust: Goは 1.27.3 または 1.26.10 以降26、Rustは webpki-roots 1.0.10 / rustls-webpki 0.103.16 以降27を用いてバイナリを再ビルドし、本番環境へ再デプロイする。 Windows（閉域網・自動更新無効環境）: インターネットに接続されており自動ルート証明書更新（CTL）が有効なWindows環境は保護済みだが、閉域網や自動CTL更新を無効化しているサーバーでは、定例外更新プログラム KB5134133 を適用するか、emudhra.we-have-a-problem.com リポジトリで提供されているPowerShellスクリプト（Block-EmudhraCompromisedCA.ps1）を用いて16枚の証明書を「信頼されない証明書（LocalMachine\Disallowed）」ストアへ登録する11314。 参考資料・出典一覧 eMudhra Intermediate CA Compromise (emudhra.we-have-a-problem.com) Apple's git still trusts the compromised eMudhra certificates (emudhra.we-have-a-problem.com/apple.html) eMudhra 中間CA証明書の秘密鍵危殆化について (emudhra.we-have-a-problem.com/ja.html) GitHub - galadran/we-have-a-problem.com (Proof artifacts, impacted-intermediates.json, roots.json) Mozilla Bugzilla - Bug 2083449: eMudhra: Private key compromise of Intermediate Certificates Mozilla Security Blog - Protecting Firefox users following the compromise of eMudhra intermediate certificates Mozilla Bugzilla - Bug 2084101: Remove emSign ECC Root CA - G3 from NSS Mozilla Bugzilla - Bug 2083709: Remove emSign Root CA - C1 and emSign ECC Root CA - C3 from NSS Mozilla Bugzilla - Bug 1970728: eMudhra: CRL signature verification failure Mozilla NSS 3.131.1 Release Notes Google Security Blog - Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates Apple Support - About the compromised eMudhra intermediate CAs (149555) Microsoft Security Response Center (MSRC) - Microsoft's response to compromised eMudhra certificate authority keys Microsoft Support - KB5134133: Out-of-band update for Windows to distrust compromised eMudhra CA certificates Cloudflare Blog - 8 eMudhra certificates are compromised. Here's what you need to know Cloudflare Blog - 4 real? Tracking exploitation and patching of eMudhra's weak keys Ubuntu Security Notice - USN-8944-1: ca-certificates update Debian Security Advisory - DSA-6572-1: ca-certificates security update Red Hat Security Bulletin - RHSB-2026-012: Distrust of eMudhra certificates (CVE-2026-114406) AWS Linux Security Center - CVE-2026-113470 (ALAS2023-2026-3306) AWS Security Bulletin - 2026-150-AWS: Compromised eMudhra Intermediate CA Certificates Google Cloud Security Bulletin - GCP-2026-071 GitHub Security Advisory - GHSA-6q48-6c7w-9gw2 (certifi) GitHub Security Advisory - GHSA-hq85-5cpj-mr62 (astral-sh/uv) Node.js - October 2026 Security Releases Go Issue #82345 - crypto/x509: distrust compromised eMudhra intermediate CAs (CVE-2026-111943) GitHub - rustls/webpki-roots Releases JetBrains Security Blog - Compromised eMudhra Certificates: Update Your JetBrains IDEs, ReSharper, .NET Tools, Toolbox App, and Gateway Now GitHub Security Advisory - GHSA-jr5w-w6x2-84p9 / CVE-2026-115570 (electron/electron) Visual Studio Code October 2026 (v1.143.1 Recovery Release Notes) Obsidian Changelog - Obsidian 1.14.5 Desktop (Public) GitHub - microsoft/vscode PR #342838: chore: bump electron@43.7.7-15743441

eMudhra 中間CAインシデント 対応確認ガイド 更新後に、使っているクライアントが対象の証明書を拒否するか確認する手順です。HTTPSなどのTLS通信を対象とし、コード署名の検証は扱いません。 まだ更新していない場合は、先に対応手順を進めてください。確認が必要な理由は前提の説明にまとめています。 ブラウザ・一般アプリの確認 開発ツールの確認 CAバンドルの直接検証 サーバーの確認 結果の判定 最終情報確認：2026年10月25日 21:12 JST。以下は確認手順であり、特定の端末での実測結果ではありません。 確認前に記録すること まず分かる項目を記録し、不明な項目は「未確認」と残します。ブラウザだけを確認する人は、名前・バージョン・更新履歴・プロキシの有無から始めてください。 開発ツールやサービスでは、次の項目も記録します。同じPCでも、Windows側、Git Bash、WSL、コンテナは分けてください。 ツール名、実行ファイルの場所、バージョン OS、WSL、venv、コンテナなどの実行環境 CAの参照先と、設定による上書きの有無 プロキシの有無 適用した更新と、その根拠となる公式告知 証明書検証を無効にした設定がないことも確認します。無効になっていた場合は、その状態を修正してから試験してください。検証を無効にしたまま接続できても、対応確認にはなりません。 ブラウザと一般アプリ ブラウザ 確認するブラウザで、インシデントサイトを開きます。 「Run check」を実行します。 一覧の各リンクを個別に開き、表示とエラー内容を確認します。警告を無視して先へ進まないでください。 結果の判定に沿って記録し、使っている別のブラウザでも繰り返します。 チェッカーの✅は、接続に失敗したことを示します。ページ側では失敗理由を区別できないため、✅だけで合格にはしません。証明書警告が出た場合も、失効・不信頼による拒否なのか、期限切れやCTの要件違反なのかを確認してください。原因を判断できなければ「未確認」と記録します。 警告なく表示された場合は、提示された証明書がテスト用のものかを確認します。企業のHTTPS検査プロキシが証明書を差し替えている場合は、プロキシ側の確認も必要です。テストサイトの説明 Electronなどの一般アプリ アプリのバージョンと、その製品の修正告知を照合します。Electronを使うアプリは、修正版Electronを組み込んだ製品版になっているかを確認してください。Electronのアドバイザリ アプリ内でテスト先を開ける場合も、その画面の結果だけでアプリ全体を確認済みにはしません。別の通信処理で別のTLS実装を使う可能性があります。製品側の説明以上に確認できなければ、「修正版へ更新済み・個別通信の試験は未実施」と残します。 テスト用ホスト 実行時には、インシデントサイトの最新一覧を確認してください。確認時点の一覧には14ホストがあります。 次の4つは、DV-G3Bという1つのTLS中間CA鍵を確認するための例です。 URL 経路・条件 dv-g3b-emudhra.we-have-a-problem.com eMudhra側の経路 dv-g3b-aaa-emudhra.we-have-a-problem.com AAA Certificate Servicesへのクロス署名経路 dv-g3b-noct-emudhra.we-have-a-problem.com eMudhra側・CT未登録 dv-g3b-aaa-noct-emudhra.we-have-a-problem.com クロス署名側・CT未登録 この4つだけでは、TLS用の中間CA6件すべてを確認したことにはなりません。必要な範囲に応じて、一覧のほかの対象も試験します。また、CT未登録の証明書はCTの要件だけで拒否されることがあるため、その失敗から中間CAの不信頼を確認することはできません。 開発ツール curl まず、実行するcurlを確認します。 WindowsのPowerShell： Get-Command curl.exe -All curl.exe --version Mac／Linux／Git Bash： type -a curl curl --version 続けて、そのcurlでテスト先へ接続します。PowerShellでは、以下の curl を curl.exe に置き換えてください。 curl --verbose --connect-timeout 10 --max-time 20 dv-g3b-emudhra.we-have-a-problem.com curl --verbose --connect-timeout 10 --max-time 20 dv-g3b-aaa-emudhra.we-have-a-problem.com curl --verbose --connect-timeout 10 --max-time 20 dv-g3b-noct-emudhra.we-have-a-problem.com curl --verbose --connect-timeout 10 --max-time 20 dv-g3b-aaa-noct-emudhra.we-have-a-problem.com --insecure や -k は付けません。終了コードだけでなく、エラー全文、表示された証明書、CAの参照先、プロキシの利用状況を記録します。CAの参照先や出力内容は、curlのTLSバックエンドによって異なります。curlの証明書検証 実行後は結果の判定へ進んでください。ログを共有する場合は、認証情報、内部ホスト名、パスなどが含まれていないか確認してください。 Python 対象のvenvやconda環境を有効にし、そのPythonを確認します。 python -c "import sys, ssl; print(sys.executable); print(ssl.OPENSSL_VERSION); print(ssl.get_default_verify_paths())" Requestsを使う環境では、次も確認します。Requestsを使っていないアプリの試験のために、新たにインストールする必要はありません。 python -c "import requests, certifi; print(requests.version); print(certifi.version); print(certifi.where())" certifi.where() が示すのはcertifiのファイルの場所です。実際のアプリがそのファイルを使うことまで保証するものではありません。REQUESTS_CA_BUNDLE、CURL_CA_BUNDLE、SSL_CERT_FILE、コード内の verify や独自SSLContextも確認してください。Python ssl、Requests Requestsの通常設定での接続例です。URLを変更し、試験対象ごとに実行します。 python -c "import requests; r=requests.get('dv-g3b-emudhra.we-have-a-problem.com', timeout=20); print('TLS接続成立 / HTTP', r.status_code)" SSLError が出た場合は、例外の詳細を読んで原因を確認します。SSLError という名前だけでは、本件の拒否かどうかはわかりません。実アプリが独自設定を使う場合は、その設定を含む処理でも確認します。その後、結果の判定に沿って記録してください。 Node.js 対象アプリと同じNode.jsを使っているか、最初に確認します。 node -p "process.execPath" node --version 次は、Node.jsの標準 fetch による接続例です。 // check-emudhra.cjs として保存し、対象のNode.jsで実行する const url = 'dv-g3b-emudhra.we-have-a-problem.com'; fetch(url, { signal: AbortSignal.timeout(20000) }) .then((response) => { console.log('TLS接続成立 / HTTP', response.status); }) .catch((error) => { console.error(error); process.exitCode = 1; }); node check-emudhra.cjs URLを変えて各対象を試します。エラーは cause や code まで確認してください。.catch() に入ったことだけで「ブロック済み」とは判定しません。Node.jsの証明書エラー一覧 同梱CA、システムCA、NODE_EXTRA_CA_CERTS、アプリ個別の ca 設定も記録します。上のスクリプトと実アプリの設定が違う場合は、実アプリの通信を別に確認してください。Node.jsのCA設定 実行後は結果の判定に沿って記録します。 Go・Rustなどの配布済みバイナリ 対象バイナリが修正を含むツールチェーン・依存関係で作られたことを、ビルド情報や製品のリリースノートで確認します。そのうえで、対象バイナリ自身の通信を試験します。 検証用プログラムで代用した場合は、対象バイナリと揃えた条件を記録してください。ホストのcurlが拒否しても、別の検証コードやCAを使うバイナリまで確認したことにはなりません。 CAバンドル ファイル形式のCAバンドルを切り分けたい場合は、インシデントサイトが配布する chains.zip と、その説明を使います。OSやブラウザの拒否リストを確認する試験とは分けてください。 インシデントサイトから chains.zip を取得し、同梱の説明を読みます。 確認するCAバンドルの実際のパスを調べます。 対象ホストのリーフ証明書と、経路構築用の中間証明書を区別します。 使用するOpenSSLのバージョンを記録し、検証を実行します。 エラー番号、深さ、対象証明書、失敗理由を記録します。 次はOpenSSL 3で、リーフを leaf.pem、中間証明書を intermediates.pem として用意した場合の書式例です。これらは説明用の名前なので、実際に用意したファイルへ置き換えてください。 openssl version openssl verify \ -CAfile /path/to/ca-bundle.pem \ -no-CApath -no-CAstore \ -untrusted intermediates.pem \ -purpose sslserver \ -verify_hostname dv-g3b-emudhra.we-have-a-problem.com \ leaf.pem 対象の証明書と経路構築用の中間証明書は、同じ位置引数にまとめません。-untrusted は経路構築に使う証明書を指定するもので、信頼するCAとして追加する指定ではありません。OpenSSL verify チェーン不足、ファイルの読み込み失敗、期限切れなどでも検証は失敗します。任意の verify error を合格扱いにはしません。また、この結果は「使用したOpenSSL・入力証明書・CAファイル・オプション」の組み合わせに対する結果です。アプリが別の検証実装を使う場合は、そのアプリでも確認します。その後、結果の判定へ進みます。 結果の判定 観測した結果 記録する状態と次の作業 検証を有効にした状態で、対象チェーンを提示するテスト先へのTLS接続が成立 要対応。更新内容、実行ファイル、CA設定を見直す。 対象鍵・証明書の失効または不信頼による拒否を、ベンダーの対策と照合できた その対象・実行条件で「拒否を確認」と記録する。 DNSエラー、タイムアウト、接続拒否 判定不能。通信経路やサービスの稼働を確認し、接続可能になってから再試験する。 期限切れ、ホスト名不一致、CT要件違反、チェーン不足 本件の対策を確認した根拠にはしない。失敗理由を切り分け、公式の修正情報と照合する。 HTTPS検査プロキシが証明書を差し替えている クライアント単独の結果にしない。プロキシ管理者へ、対象の拒否状況を確認する。 エラーの理由やCAの参照先を特定できない 未確認。ログを保存し、製品のサポートや管理者へ確認する。 HTTP 404や500と、TLSの検証失敗は別です。HTTP応答を受け取るところまで進んでいるなら、通常はその前にTLS接続が成立しています。 サーバー サーバーでは、サービス、バッチ、監視エージェント、CIジョブごとに確認します。 更新したプロセスやコンテナが、実際に稼働していることを確認します。 実行ファイル、ランタイム、コンテナのイメージdigestを記録します。 実際のサービスと同じ設定・ユーザー・ネットワーク経路で接続試験を行います。 結果の判定に沿って、原因を確認します。 通常の接続先でも通信できることを確認し、正規サイトへの接続エラーが増えていないか確認します。 対話シェルとサービスでは、CA設定やプロキシが違うことがあります。サービス自身で試験できず、代わりのプログラムを使った場合は、その制限を記録してください。 確認結果を残す 次の表を、確認対象ごとに埋めます。以下は記入例のひな型で、実測結果ではありません。 対象・実行環境 実行ファイル／版／CA設定 更新の根拠 試験日時・対象・エラー 判定・残件 例：WSLのcurl 要記入 公式告知URL 未実施 未確認 例：サービスAのvenv 要記入 公式告知URL 未実施 未確認 判定は次の4つに分けると、未完了の作業がわかります。 確認済み：拒否を確認できた対象と条件を併記する。 更新済み・試験未了：修正版は適用したが、試験できていない。 要対応：対象を受け入れる、修正未適用など、対応が残っている。 未確認：対象や設定が不明、エラー原因が不明、試験から漏れている。 確認していないアプリやサービスまで、まとめて「端末全体で完了」とは記録しないでください。 更新履歴 日付（JST） 内容 2026-10-25 対応手順・前提説明から分離。接続失敗の原因確認、対象範囲、結果の記録方法を整理。 最終確認：2026年10月25日。試験用ホストとベンダーの対応状況は変わるため、実行時には参照先の最新情報を確認してください。

eMudhra 中間CAインシデントの対応と確認を整理する eMudhra の中間CAに関するインシデントについて、muse と整理した背景・対応手順・確認方法のメモを、1本の記事にまとめました。 この記事の主題は、更新のあとに 「何を、どこまで確認できたか」 を整理することです。一般利用のPC、開発用PC、サーバーの順に扱います。 最終情報確認：2026年10月25日 20:44 JST 本文は公開資料に基づく整理です。コマンドは確認方法の例であり、特定の端末での実測結果を示すものではありません。コード署名の検証は対象外とし、主にHTTPSなどのTLSクライアントを扱います。 先に結論 OSだけでなく、ブラウザ、アプリ、ランタイム、コンテナまで更新対象を洗い出します。 確認単位は「PC 1台」ではなく、実行ファイル・設定・信頼ストアを含む証明書の検証経路です。 テスト先への接続が失敗しても、それだけでは対応済みと判断できません。失敗理由と提示された証明書を確認します。 「更新済み」「試験で確認済み」「未確認」を分けて記録します。確認していない範囲を完了扱いにしません。 会社や学校に管理されている端末では、独自に証明書ストアを変更せず、管理者の案内に従ってください。 何が起きたのか eMudhra が運用する中間CAの秘密鍵について、第三者による復元が確認されました。対象は TLS用の中間CAが6件、コード署名用が2件です。「8件すべてがTLS用」という整理は正確ではありません。技術的な報告は Mozillaのインシデント票に集約されています。 TLS用の6件にはそれぞれ2つの証明書があり、eMudhra側のルートへ至る経路と、Sectigoによるクロス署名で AAA Certificate Services へ至る経路があります。したがって、eMudhraのルートを1つ外しただけでは、すべての経路を拒否できるとは限りません。Appleの説明 影響を受けるTLSクライアントでは、偽造されたサーバー証明書を受け入れるおそれがあります。一方で、鍵を復元できたことと、実際に通信が盗まれたことは別です。Googleは遮断前に対象のTLS中間CAから発行された証明書がCTログに登録されていなかったと説明していますが、この説明をCTを強制しないクライアントにまで広げることはできません。Googleの説明 eMudhraは2026年10月22日、グローバルなSSL/TLS証明書事業からの自主撤退を発表しています。これは同社の認証関連事業すべてが終了するという意味ではありません。eMudhraの発表 ブラウザが直っても、ほかの通信経路が残る 対策には、ベンダーによる拒否情報の配信、CAバンドルの変更、証明書検証コードの修正などがあります。どれが必要かは製品と実装によって異なります。 主要ブラウザでは、本体の更新とは別経路の配信が先行しました。 対象 公式情報で確認できた対応 Chrome 10月17日にCRLSetで対象鍵を遮断。本件の配信にブラウザの更新・再起動は不要と説明されています。Google Firefox 標準構成では10月17日のOneCRL配信で保護。カスタム設定やAndroid固有の問題に向けた追加修正も案内されています。Mozilla Appleのネットワーク・セキュリティフレームワークを使うアプリ Appleは10月19日から対象中間CA、10月23日から対象ルートも自動ブロックしたと説明しています。証明書構成データの自動配信であり、この変更の受信にOS本体の更新は不要です。Apple これらは、同じ端末で動くすべてのアプリが同じ保護を受けるという意味ではありません。 たとえばcurlは、ビルドされたTLSバックエンドや設定によって、OSのネイティブストアを使う場合とファイル形式のCAストアを使う場合があります。curl という名前だけでは判断できません。curlの証明書検証ドキュメント 最初に確認範囲を決める 棚卸しでは、少なくとも次を1組として記録します。 何が通信するか：ブラウザ、CLI、アプリ、サービス、監視エージェントなど。 どこで動くか：ホストOS、WSL、仮想環境、コンテナ、CIランナーなど。 何で検証するか：TLS実装、CAストア、追加CA、プロキシ、検証を変更する設定。 同じ名前のツールでも、配置場所や実行環境が異なれば別の行にします。たとえば、Windowsの curl.exe、Git Bashのcurl、WSL内のcurlを、1回の試験でまとめて確認したことにはしません。 記録には次のような欄があると、後から見直しやすくなります。以下は記入用のひな型で、確認結果ではありません。 対象・実行環境 実行ファイル／版 TLS実装・CAの参照先 更新の根拠 試験日時・結果 判定・残件 例：WSL内のcurl 要記入 要調査 公式告知URL 未実施 未確認 例：サービスAのPython環境 要記入 要調査 公式告知URL 未実施 未確認 例：コンテナB イメージdigest等 要調査 修正を含むビルド情報 未実施 未確認 CAの参照先がわからなければ、まず「要調査」と書いておきます。推測で「OSと共通」にしないことが大切です。 一般利用のPCで行うこと ターミナルを普段使わない人が、証明書ファイルの手動編集から始める必要はありません。 OS、利用中のブラウザ、アプリについて、通常の更新を適用します。再起動を求められたものは再起動します。 更新の一時停止や組織の配信制御がある場合は、管理者に本件の対応状況を確認します。 アプリの公式告知で、本件の修正がどのリリースに含まれるかを確認します。「最新版」という表示だけを根拠に、未発表の修正まで入っているとは判断しません。 ブラウザを試験する場合は、使っているブラウザごとに、後述のテストサイトを開きます。証明書警告を無視して先へ進まないでください。 Electronを使うアプリなど、アプリ側に実行環境を含む製品は、OSとは別に製品側の対応確認が必要です。Electron公式は修正版への更新を必要としています。アプリのバージョンと、その製品の修正告知を対応づけます。アプリ内の1画面で拒否できても、別の通信処理まで同じ経路とは限りません。Electronのアドバイザリ 個人利用でも、わからないものは「未確認」で構いません。ベンダーの案内を待つ間、重要な用途を対応状況の確認できるクライアントに切り替えることを検討します。 開発用PCでは、同梱ツールと実行環境を追加する WindowsのGitとcurlを分ける Gitの http.sslBackend は、Gitが利用するSSLバックエンドの設定です。schannel を選べる構成でも、これによって Git Bashで単独実行するcurlの設定まで変わるわけではありません。Gitとcurlを別々に記録・確認します。Gitの設定ドキュメント 次は設定を変更しない確認例です。 PowerShell：どの実行ファイルが見つかるか Get-Command git.exe, curl.exe -All curl.exe --version git --version git config --show-origin --get http.sslBackend http.sslBackend が表示されない場合は「設定が明示されていない」という意味です。それだけで使用中のバックエンドは確定しません。URL別設定や追加CA、環境変数による上書きも確認対象です。 WSLの各ディストリビューションや、その中の言語環境はWindows側とは分けて棚卸しします。 macOSのアプリとCLIを分ける Appleは、一部のmacOS／Xcode Command Line Tools同梱ツールが /etc/ssl/cert.pem を参照し、Appleの自動ブロックを使わないことを説明しています。2026年10月25日の確認時点では、そのファイルへの対応は将来のmacOS更新として案内されています。Appleの説明 したがって「Safariで拒否されたので、同梱curlやgitも確認済み」とはしません。Homebrew等で入れた同名ツールについても、実体、利用するライブラリ、更新内容を個別に確認します。 この記事では /etc/ssl/cert.pem の手動削除手順は掲載しません。ルートを広く削除すると、今回の問題と無関係な証明書も検証できなくなる可能性があります。修正版クライアントへの移行やベンダー更新を優先し、暫定措置が必要な管理環境では、管理者が公式手順・影響範囲・復旧方法を確認して判断します。 言語名だけでストアを決めつけない 実行環境 確認すること Python 仮想環境ごとに、実際のHTTPライブラリとCA設定を確認します。Requestsは通常certifiを使いますが、verify や環境変数で参照先を変更できます。Python全体が必ず同じストアを使うわけではありません。Requests Node.js Node本体の版に加え、同梱CA、システムCA、追加CA、アプリ個別の ca 設定を確認します。利用できる設定は版によって異なります。Node.js TLS Go OSの証明書を利用する構成もあります。ストアだけでなく、今回の修正を含む検証コードでビルドされた配布物かを確認します。SystemCertPool、今回の修正 Rust rustls系かnative-tls系か、CAを同梱するかなどを確認します。たとえばnative-tlsはプラットフォームごとに異なるTLS実装を利用します。native-tls Java 利用中のJDKと、javax.net.ssl.trustStore などの指定を確認します。「OSを更新したのでJDKも同じ状態」とは仮定しません。Oracle JSSEガイド 更新対象には、依存関係のロックファイルや、アプリへコピーしたCAバンドルも含めます。ライブラリや検証コードをバイナリに組み込んでいる場合、開発用ツールチェーンを更新しただけでは既存の配布物は変わりません。対象の修正版を入手するか、必要な更新を反映して再ビルド・再配布します。 接続テストの読み方 テスト先と確認できる範囲 インシデントサイトでは、確認用のホストと証明書チェーンが公開されています。実行時には同サイトの最新の対象一覧を確認してください。 よく挙げられる次の4ホストは、DV-G3Bという1つのTLS中間CA鍵について、通常経路／クロス署名経路とCT登録の有無を組み合わせた例です。4つの試験だけで、6件のTLS中間CAすべてやコード署名まで網羅したことにはなりません。 dv-g3b-emudhra.we-have-a-problem.com dv-g3b-aaa-emudhra.we-have-a-problem.com dv-g3b-noct-emudhra.we-have-a-problem.com dv-g3b-aaa-noct-emudhra.we-have-a-problem.com サイトのチェッカーで✅が出ても、それが意味するのは接続失敗だけの場合があります。また、No CTの証明書はCTの要件だけで拒否されることがあるため、その失敗から中間CAの拒否を確認することはできません。 「失敗した」からもう一段確認する 試験前に、設定ファイルやアプリのコードで証明書検証を無効化していないか確認します。普段の通信が検証なしで動いていた場合、その状態自体が修正対象です。 観測した結果 判断 検証を有効にした状態で、対象チェーンを提示するテスト先へTLS接続できた その条件では対象を受け入れています。更新・設定・経路を見直します。 対象鍵／証明書への拒否が、ベンダーの対策と整合する形で確認できた その試験対象・実行条件の範囲で拒否を確認できた、と記録します。 DNS失敗、タイムアウト、接続拒否 TLS検証まで到達していない可能性があり、判定不能です。 期限切れ、ホスト名不一致、CT要件違反、チェーン不足など その証明書は拒否されても、本件への対策が入った根拠にはなりません。 HTTPS検査プロキシが別の証明書に差し替えている クライアント単独の検証結果として扱えません。プロキシ側も確認対象にします。 HTTPのステータスコードとTLSの成否も分けます。HTTP 404や500が返るところまで進んでいるなら、通常はその前のTLS接続は成立しています。 curlの例 まず実行するcurlの実体とTLSバックエンドを確認し、そのcurlで試します。 bash / zsh の例 type -a curl curl --version 1ホストの確認例。対象一覧の各ホストを別々に確認する curl --verbose --connect-timeout 10 --max-time 20 \ dv-g3b-emudhra.we-have-a-problem.com 終了コードだけでなく、エラー全文、提示された証明書、CAの参照先、プロキシの有無を確認します。curl -v の出力などから参照先を調べられる場合がありますが、表示内容はバックエンドで異なります。curlの説明 -k／--insecure は付けません。 証明書検証を無効にしてしまうため、今回の確認には使えません。ログを共有する場合は、認証情報、内部ホスト名、パスなどが含まれていないか確認してください。 PythonやNode.jsでも、実際のアプリと同じ環境・設定から試すことが重要です。Pythonの SSLError は本件以外でも発生します。Node.jsの .catch() も、証明書以外のエラーを受け取ります。「例外が出たらBLOCKED」とだけ表示するコードでは、対応判定に必要な情報が失われます。Requestsの例外例、Node.jsの証明書エラー一覧 CAバンドルを直接調べる場合 インシデントサイトの chains.zip を使ったオフライン検証は、ファイル形式のCAバンドルの切り分けに使えます。ただし、OpenSSLでそのファイルを検証した結果は、OSやブラウザ独自の拒否リストの状態を直接示しません。 実行時は配布物の説明と、利用中のOpenSSLのドキュメントを確認してください。OpenSSLでは、検証対象の証明書と、経路構築に使う中間証明書の -untrusted、信頼するCAの -CAfile を区別します。単にチェーン全体のPEMを1つ渡し、何らかの verify error が出たことだけで成功扱いにはしません。OpenSSL verify 入力チェーンが揃っているか、想定したCAだけで検証しているか、有効期間や用途が適切か、どの深さのどの証明書で失敗したかを記録します。 サーバーとコンテナで追加すること サーバーでは、対話シェルのcurlだけでなく、実際に外部へ通信するサービス、バッチ、監視エージェント、CIジョブを対象にします。 更新作業は次の単位で分けて管理すると、取りこぼしを見つけやすくなります。 ホスト：ディストリビューションの修正告知に従い、対象パッケージと必要な設定を更新する。 アプリ：ランタイム、依存ライブラリ、独自CAバンドル、固定された依存関係を確認する。 コンテナ：修正を含むベースイメージと依存関係で再ビルドし、再デプロイする。稼働中のイメージdigestも記録する。 実行中プロセス：更新済みファイルを再読込できているか確認し、製品の案内に従って再起動・再デプロイする。 CI：ビルドするホスト、ランナー、ジョブで使うイメージを分けて確認する。 Docker Desktopなどのホスト側製品を更新しても、既存のアプリ用コンテナイメージまで自動で書き換わるわけではありません。製品自体の修正範囲と、自分が配布するイメージの更新を分けて扱います。Dockerのリリースノートにはコンポーネントごとの段階的な対応の説明もあるため、版番号だけで一括して完了扱いにしないようにします。Docker Desktopリリースノート 試験も、本番サービスと同じバイナリ・設定・実行環境で行います。別の検証用プログラムで代用した場合は、同じ条件に揃えられた点と、確認できていない点を残してください。 自分のサイトが対象の証明書を使っている場合 クライアントの更新とは別に、公開しているサーバー証明書のチェーンを確認します。 Googleは emSign ECC Root CA - G3 のChrome Root Storeからの削除を、2026年10月27日午前（PDT）に配信予定としています。該当する運営者には、別の信頼されるPKI階層で証明書を取得・設置するよう案内しています。これは予定であり、本記事の確認時点で全端末への配信完了を確認したものではありません。Googleの案内 対象なら発行元やCDN、ロードバランサーの管理者と更新を進め、切り替え後の証明書チェーンと接続エラー率を確認します。 どこで「確認できた」とするか この記事では、次のように状態を分けることを提案します。 確認済み（範囲付き）：対象、実体、設定、更新根拠がわかり、その検証経路で必要な拒否を確認できた。 更新済み・試験未了：公式の修正は適用したが、その環境での試験はまだできていない。 要対応：対象チェーンを受け入れる、修正未適用、またはベンダーが未対応と案内している。 未確認：参照ストアが不明、エラー原因が不明、試験対象から漏れているなど、判断材料が足りない。 「このPCは安全」と1行でまとめるより、「この実行ファイルを、この設定で、ここまで確認した」と書くほうが、引き継ぎにも後日の再確認にも使えます。 この記事の更新方針 修正版の番号は製品・ブランチ・配布元によって異なり、段階的な対応もあります。そのため、この記事では網羅的な「この番号以上なら対応完了」という表を置いていません。 更新を確認するときは、次の順で見直します。 インシデントサイトで、新しい対象や修正情報、テスト方法の変更を確認する。 リンク先のベンダー公式告知、リリースノート、インシデント報告と照合する。 「発表された」「配信予定」「配信開始」「手元で適用を確認」を混同せずに本文へ反映する。 読者の対応が変わる差分を更新履歴に残す。 コミュニティの集約情報とベンダーの説明に差がある場合は、対象範囲と確認日を比較します。たとえばAppleの配信開始日は、この記事ではApple公式の記載を採用しています。原因や悪用状況など、確定していない点は断定しません。 参照資料 本件の経緯と対策 eMudhra Intermediate CA Compromise（コミュニティによる集約・テストサイト） Mozilla Bugzilla インシデント報告 Google Chrome／Android向け説明 Mozilla Firefox向け説明 Appleの対応とmacOS CLIに関する説明 eMudhraのSSL/TLS事業撤退の発表 検証経路を調べるための資料 curl TLS Certificate Verification Git git-config Requests SSL Cert Verification Node.js TLS OpenSSL verify 更新履歴 日付（JST） 内容 2026-10-25 初稿。背景、更新対象、確認方法を統合。公式情報と照合し、TLSとコード署名の対象区分、Appleの配信情報、接続失敗の判定条件を整理。 最終確認欄 公開資料の確認日時：2026年10月25日 20:44 JST 本文が扱う範囲：主にTLSクライアントの更新と確認。コード署名の検証は対象外。 実機試験：この記事には個別端末の実測結果を掲載していません。 継続確認する点：macOS同梱CLI向け更新、各製品の修正範囲、Chromeの対象ルート削除の配信状況、原因・悪用状況に関する新たな確定情報。

electron: The Hottest C++ Repo on GitHub Right Now In this video, we break down electron/electron - one of the hottest open-source projects on GitHub right now. :electron: Build cross-platform desktop apps with JavaScript, HTML, and CSS. It has already earned 123,458 stars on GitHub and is written primarily in C++. We look at what it does, why developers are paying attention to it right now, and who should try it. 📂 Repo: electron/electron 🌐 Stars: 123,458 | Language: C++ | Forks: 17,681 🔔 Subscribe for daily picks of the hottest GitHub repos: / @reporadar #github #opensource #programming keywords: coding, developer tools, github, opensource, programming, software, tech

electron: The Hottest C++ Repo on GitHub Right Now #Shorts In this video, we break down electron/electron - one of the hottest open-source projects on GitHub right now. :electron: Build cross-platform desktop apps with JavaScript, HTML, and CSS. It has already earned 123,458 stars on GitHub and is written primarily in C++. We look at what it does, why developers are paying attention to it right now, and who should try it. 📂 Repo: electron/electron 🌐 Stars: 123,458 | Language: C++ | Forks: 17,681 🔔 Subscribe for daily picks of the hottest GitHub repos: / @reporadar #github #opensource #programming keywords: coding, developer tools, github, opensource, programming, software, tech #Shorts

Read an Electron app's fuses, runtime and ASAR integrity from the release ZIP, without running it Most Electron hardening lives outside your JavaScript. Which Electron, Chromium and Node a build ships, which fuses are flipped, and whether the app.asar is covered by an integrity hash are all decided at packaging time and baked into the binary. You won't see any of it in a code review of main.js. You can read all of it back from the shipped files. Here is what that looks like on two public releases of Electron Fiddle (MIT, the official Electron playground), straight from the macOS release ZIPs on GitHub. Nothing is unpacked by hand and nothing is executed. One command per build npx hexvero analyze Electron.Fiddle-darwin-arm64-0.39.0.zip The relevant part of the output: Runtime Electron 40.8.5 · Chromium 144.0.7559.236 · Node 24.14.0 read from Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework support: Electron 40.8.5 is past its end of support (2026-07-01, from the snapshot of 2026-10-18, as of 2026-10-24); 40.8.5 was released on 2026-03-26 fuses: runAsNode off, cookieEncryption off, nodeOptions off, nodeCliInspect off, embeddedAsarIntegrityValidation off, onlyLoadAppFromAsar on, loadBrowserProcessSpecificV8Snapshot off, grantFileProtocolExtraPrivileges on ASAR integrity: covers the loaded archive Where each line comes from: - Versions. The Electron Framework binary contains the user-agent fragment Chrome/<version> Electron/<version> and Node's release URL. A universal binary holds one copy per architecture, and the value only counts as known if all copies agree. - Fuses. Electron writes them as a small wire right after a fixed sentinel string in the binary: a schema byte, a count byte, then one byte per fuse (0 off, 1 on, r removed). That's the same wire @electron/fuses flips when you package. - ASAR integrity. On macOS this is ElectronAsarIntegrity in Contents/Info.plist: a hash of the archive's header. hexvero hashes the header of the app.asar actually in the bundle and says whether the record covers it. - Support. This compares the version against a dated snapshot of Electron's release data. It doesn't claim anything about vulnerabilities. The detail worth a second look Fiddle's bundle carries an integrity record that matches its app.asar, but the fuse embeddedAsarIntegrityValidation is off. Per Electron's docs, that fuse is what makes Electron check the record when it loads the archive. So the hash ships, but nothing verifies it at startup. Packagers write the record by default; the fuse is opt-in. That isn't a vulnerability claim about Fiddle, which is a developer tool. It's the kind of fact that's invisible unless you read the bundle, and it matters for anything that relies on the archive not being swapped on disk. Trail of Bits' CVE-2025-55305 write-up shows why this area deserves attention: they bypassed ASAR integrity through V8 heap snapshots in Signal, 1Password and Slack. What changed between 0.38.0 and 0.39.0 npx hexvero compare Electron.Fiddle-darwin-arm64-0.38.0.zip Electron.Fiddle-darwin-arm64-0.39.0.zip runtime runtime: 0 added, 0 removed, 3 changed, 12 unchanged · matched by item ~ electron value: "40.1.0" → "40.8.5" ~ chromium value: "144.0.7559.96" → "144.0.7559.236" ~ node value: "24.11.1" → "24.14.0" A patch-level Electron bump, and no fuse moved. The same comparison also covers the app's code, so other collections show what the release actually added: ipc ~ .webpack/renderer/main_window/preload.js::ipcRenderer.invoke::NPM_ADD_MODULES args: "({dir, packageManager}, ...)" → "({dir, packageManager, useSocketFirewall}, ...)" storage + .webpack/renderer/main_window/index.js::localStorage::isUsingSocketFirewall::write endpoints + .webpack/sfw/dist/sfw.mjs::http-client::https://api.github.com/repos/SocketDev/sfw-free/releases/latest That lines up with the release: 0.39.0 added an option to install packages through Socket's firewall. A new field travels over an existing IPC channel, there's a new persisted setting, and a bundled CLI calls GitHub's API. All three are visible from the ZIPs alone. Turn it into a release gate The question that matters at release time is "did this build get weaker than the last one?", not "is this build perfect?". hexvero check has a fuse-weakened rule for exactly that. It fails when a fuse moves to its less safe state (runAsNode, nodeOptions, nodeCliInspect or grantFileProtocolExtraPrivileges turned on; embeddedAsarIntegrityValidation, onlyLoadAppFromAsar or cookieEncryption turned off), when an integrity record stops covering the archive Electron loads, or when the Electron line goes past end of support: npx hexvero init previous/YourApp.app # writes .hexvero/policy.json npx hexvero check previous/YourApp.app dist/YourApp.app --policy .hexvero/policy.json # exit 0 pass, 3 violated, 4 not decidable It writes SARIF if you want the result in GitHub code scanning. The same policy also covers new IPC channels and preload members, more permissive webPreferences, and new external hosts. Limits - It reads bytes and never runs the app. A fuse that's on doesn't prove the behavior it guards is reachable, and a passing check isn't a security verdict. - Linux builds have no integrity record to read. Installers (.dmg, setup .exe, AppImage) need to be installed or unpacked first; .app bundles, install directories and release ZIPs are read as they are. - Anything it can't read is reported as unknown, never silently as "fine". hexvero is open source (MIT): maximilianfeix/hexvero. If it reads something wrong on your own builds, an issue with the output is the most useful feedback I can get. Written with AI assistance. Every command and output above is real, from hexvero 0.11.1 on the official Fiddle release ZIPs, run on 2026-10-24.

印度证书服务商 eMudhra 那个事，Electron 也发了新的安全升级版。如果你的应用完全不访问网络，那就没有影响，可以什么也不用做，否则建议还是尽快升级。 github.com/electron/electron/security/advisories/… 🔐

今見たところ、Electron側の対応は以下のリリースで対応済みのようです。(Chromiumのパッチを待たない、独自パッチの模様) github.com/electron/electron/releases 元ポストで10/27以降になると書きましたが現時点で各アプリ側でアップデートすれば修正されているかもしれません。