eMudhra中間CA証明書問題
ベンダー・ソフト別の対応状況（当社確認 2026年10月24日）

読み方と凡例

医療機関向けの注意喚起は「OSとブラウザを更新して確認サイトで確かめ、業務システムは保守事業者に確認する」までを扱いました。本資料はその先、保守事業者とIT担当者が自分の管理範囲で何を更新し、何を確かめるかを扱います。問題の中間CA証明書は、emSign ECC Root CA - G3配下の8本と、SectigoのAAA Certificate Servicesによるクロス署名8本の計16本です。^[1]

サマリー

言語ランタイムとCAバンドル

確認サイトの「Who has patched?」に載る修正版を、各プロジェクトの一次資料で照合しました。重要なのは「Windows/macOSでOSの検証機構まで使うか、OSのストアから証明書を読み込むだけか、同梱のバンドルを使うか」です。OSの検証機構を使うものはOSの更新で足り、同梱のバンドルを使うものはランタイム自体の更新が要ります。OSのストアから証明書を読み込むだけのものは、OS側の不信頼設定が検証に反映されるとは限らないので、実際の経路で確かめます。^[1]

Mozillaの指針（dev-security-policy、10/20）: 失効確認をして接続を閉じられないクライアントは、「中間CAの遮断」か「署名元ルートの削除」のどちらかを取る。^[13] 医療機関特有の業務ソフトが同梱するランタイムについての一次資料は、当社が確認した範囲では見当たりません。

デスクトップアプリとブラウザ

診療所のパソコンに入っていることが多いアプリについて、OSの証明書ストアを使わず独自に検証するもの（独自の信頼ストア、または同梱のChromium/Electron）の公式声明と修正版を照合しました。確認サイトの接続統計には、10月23日時点でEdge on Windows・Samsung Internet・アプリ内ブラウザ（Android・iOS・LINE）からの接続、つまりまだ問題の証明書を信じているクライアントが多数記録されています。^[2]

ネットワーク機器・複合機・セキュリティソフト

日本の診療所に多いベンダー29社について、公式のセキュリティ勧告・サポート記事・リリースノートを探しました。公式の案内があったのは3社（Cisco・Fortinet・Sophos）です。「見当たらず」は「影響なし」の意味ではありません。

国内の公的機関・ベンダー・端末ソフト

公的機関・業界団体（10月24日 09:47時点）

電子カルテ・レセコン・クリニック向けクラウド

医療機関の端末に入る「ブラウザ以外でHTTPS接続するソフト」の公式記述

保守事業者・IT担当者の確認手順

Cloudflareが自社の対応として説明している範囲（同梱や独自の信頼ストアを持つアプリは別に評価して更新する、更新には再読込・再起動・イメージ再配備を伴わせる、実際のTLSの経路で検証する）と、OpenJDK・Electron・確認サイトの案内から組み立てました。医療機関からの問い合わせ文例（注意喚起05章）の設問2〜4に対応します。^[5][7][8][1]

1. 経路の棚卸し。製品と管理端末で、外部とHTTPSで通信する処理を列挙する（サーバ、端末、コンテナ、外部API連携、自動更新、遠隔保守、クラウド連携）。
2. 検証器の特定。各経路で証明書を検証しているのが誰かを突き止める。OSのストアか、言語ランタイムの同梱バンドルか、アプリ同梱のChromium/Electronか、独自の設定か。SDKを更新しても下層の検証ポリシーは変わらないことがある。^[5]
3. 更新。02〜04章の修正版へ更新する。OSのストアに依存するものはOSの更新（Windowsは certutil -verifyctl Disallowed | findstr /i lastsynctime で一覧の受信日時を確認）。Javaは修正版へ更新したうえで、Oracleの専用ページ（10/23更新）に従い、JVM再起動前にルート2本の削除か失効確認の有効化を行い、複数の単体Javaがあればそれぞれに行う。更新できない場合はOpenJDKが示す遮断リストの差し替えか失効確認の有効化。Oracleの CheckCerts.java で状態を確認できる。^[6][7][11]
4. 反映。ファイルの更新だけで終わらせず、稼働中のプロセスの再起動、コンテナイメージの再構築と再配備、配布物の再配布まで行う。^[5]
5. 検証。その製品自身のTLSの経路で、確認サイトの検査用ホストへの接続が証明書エラーで失敗することを確かめる（確認サイトは、接続失敗は通信障害でも起こるので、失敗の理由まで見るよう案内している）。CT未記録の2系統（No CT）にも接続できないことを確かめる。CTを強制しないクライアントは、気づかれずに攻撃されうる側だと確認サイトは説明している。ブラウザでの成功はバックグラウンドのサービスの安全を証明せず、curlでの成功も検証器が異なれば同じ。^[1][5]
6. 無効化しない。更新後に証明書エラーが出ても、検証を無効にして解消しない。^[5]
7. 10月27日以降。ChromeがemSign ECC Root CA - G3をルートストアから削除する。自社サービスのサーバ証明書がこのルート配下なら、別系統の証明書に差し替える。^[3]
8. 回答。医療機関には「調べた範囲」「反映の完了（版と日付）」「製品自身での確認」の3点を書いて返す。

当社の対応

当社の公開サイト（www.jmedic.co.jp）の証明書は、本件の認証局が発行したものではありません。本資料は、当社が2026年10月24日に各社の公式情報を照合した記録であり、各医療機関の端末や業務システムの構成を当社が把握しているものではありません。保守事業者とIT担当者の皆さまは、本資料を出発点として、自身の管理範囲で一次資料を確かめてください。

当社保守のお客様は、お問い合わせフォームからご相談ください。保守契約のない医療機関の皆さまからの個別のお問い合わせは受けかねますが、公開できる情報は本資料や注意喚起で発信していきます。

出典と、確認できていないこと

本文の番号つき出典は以下のとおりです。各表の中のリンクは、そのベンダー・プロジェクトの公式ページで、すべて2026年10月24日に取得しました。発表主体自身の説明は、独立した第三者による事実認定とは区別しています。

1. eMudhra Intermediate CA Compromise（確認サイト）Dennis Jackson氏（Mozilla）が公開。問題の中間CA 8本とクロス署名8本の一覧（impacted-intermediates.json）、ブラウザ検査、ブラウザ以外の検査手順、修正済みソフトの一覧（Who has patched?）。
2. 同 接続統計（user-agent別）まだ問題の証明書を信じているクライアントの接続回数。
3. Google Security Blog（2026-10-20）CRLSetによる遮断（10/17 19:45 UTC）、Androidへの配信、emSign ECC Root CA - G3の10/27（PDT）削除予定。
4. Mozilla Security Blog（2026-10-20）OneCRL配信（10/17 22:59 UTC）、NSS 3.131.1でのルート削除、Firefox 158.0.1／ESR、Android 158.0.2。
5. Cloudflare Blog（2026-10-20）自社の対応範囲（同梱・独自の信頼ストアは別評価、再読込・再起動・再配備、実際のTLS経路での検証）、開発者向け指針（SDKの下層を見る、検証を無効化しない、ブラウザやcurlの成功は代わりにならない）。
6. Oracle Security Alert Advisory CVE-2026-91403（2026-10-21）対象版、最新版への更新か緩和策（Rev 1）。専用ページ ops.java/emudhra（10-23更新）は、修正版に更新済みでもJVM再起動前にルート2本の削除か失効確認の有効化を求め、CheckCerts.java を提供。
7. OpenJDK Vulnerability Advisory 2026/10/21単体ランタイムは更新、blocked.certsの差し替えか失効確認の有効化、OS同梱のOpenJDKはOSの証明書で足りる。
8. Electron Security Advisory GHSA-jr5w-w6x2-84p9（2026-10-22）ChromiumネットワークとNode.jsのtls/https/fetchの両方に遮断。アプリ側の回避策なし。修正版44.9.1／43.8.1／42.11.16／45.0.0-beta.6。
9. Cisco Security Advisory（Informational）cisco-sa-emudhra-info-ScS22A1r（2026-10-23）調査中・影響あり・修正版の製品一覧。未掲載製品は影響なし。
10. Fortinet Community Technical Tip（2026-10-21）FortiGuardへの接続は専用のCA一覧のため影響なし。SSL検査の信頼CAの残存と無効化手順。
11. Microsoft Learn：Configure trusted roots and disallowed certificates in Windows信頼しない証明書の一覧の自動更新の仕組み、切断環境、certutilでの確認。
12. Microsoft：KB2677070Windows 7・Server 2008 R2等向けの「信頼しない証明書の自動更新」。切断環境には効果なし。
13. Mozilla dev-security-policy：Compromised eMudhra Intermediate Certificates（2026-10-20）信頼ストア運営者向けの指針（中間CAの遮断か、署名元ルートの削除）。
14. eMudhra Press Release（2026-10-22）世界向けSSL/TLS証明書事業からの撤退。発行元自身の発表。
15. Python 公式告知（Discourse、2026-10-20）certifiとpipの更新、すべての既存の仮想環境でpipを更新。
16. pip 公式文書：HTTPS Certificates既定でcertifiに加えてシステム証明書を使う。
17. Node.js 公式文書：--use-system-ca同梱CAストアはリリース時点のMozillaストアのスナップショットで全プラットフォーム同一。
18. Go 公式文書：crypto/x509macOS・WindowsではシステムAPIが証明書検証を担う。
19. .NET 公式文書：Cross-platform cryptographyWindowsはWindows証明書ストアとその検証機構、LinuxはOpenSSLのCAバンドル、macOSはSecTrustSettings。
20. 医療情報基盤・診療報酬審査支払機構：オンライン請求システム再セットアップ方法（令和8年10月）Mac区分のみOracle製Javaのインストール手順。

確認できていないこと

• AppleとMicrosoftの公式発表（遮断日は確認サイトの記載による）。
• Windows 10のEdgeが10月20日以降に遮断されたかどうか。Edge WebView2がどの信頼ストアを使うか（公式記述なし）。
• サポート終了のWindowsに「信頼しない証明書の一覧」が現在も届くか（公式記述なし）。
• Zoom・Teams・Slack・Chatwork・Discord・Notion・LINE WORKS・LINE・Opera・Arcと、クラウドストレージ・リモート操作ツール各社の公式声明。
• Java配布元のうちEclipse TemurinとMicrosoft Build of OpenJDKの対応表明。.NETランタイムの公式見解。
• 国内のルータ各社・複合機各社・NAS各社・セキュリティソフト各社の公式声明（ESETを除き検証ストアの種類も未確認）。Check Point・WatchGuard・Juniper・SonicWall・Palo Alto（自社製品の影響）の公式勧告。
• 国内の電子カルテ・レセコン等12社の公式告知での言及。ラボテック・きりんカルテ・医療ISACは取得不可。
• 医療機関特有の業務ソフトが同梱するランタイムとその更新状況（一次資料なし）。

本資料は、各社の公式情報を2026年10月24日に照合して作成した、保守事業者・IT担当者向けの付属資料です。照合は生成AIのサブエージェント4体（言語ランタイム／デスクトップアプリ／ネットワーク機器等／国内）で行い、一次資料のURLと日付を記録し、公開前の内容確認は当社が行いました。X・生成AIの出力・まとめ記事は証拠にしていません。攻撃の再現や第三者システムへの検証は実施していません。公開後に追加で分かったことは、日付を付けて追記します。10月24日の公開後の見直しで、Python標準 ssl の扱い（OSのストアから証明書を読み込むことと、OSの検証機構を使うことの区別）、サマリーの日付表記、日付の基準、出典10の表現を修正しました。