サマリー
何が起きたのですか？
Webサイトが本物であることを証明する「電子証明書」を発行する認証局の一つ、eMudhra（インド）で、8本の中間CA証明書の秘密鍵が、鍵を作るときの乱数が不十分だったために第三者に導き出せる状態だったことが、10月17日に研究者からGoogle・Mozilla・Apple・Microsoftへ報告されました。この鍵を持つ者は、対策前の端末に対して、どんなWebサイトにもなりすます偽の証明書を作れます。[1][2][3]
慌てる必要はありますか？
対策は各社が自動で配信しています。ChromeとFirefoxは17日中に、Androidは19日に、Windowsは20日に、Apple製品は22日に、問題の証明書を遮断しました（WindowsとAppleの日付は確認サイトの記載によります）。eMudhraは、この8本から利用者向けの証明書は一度も発行しておらず、開示前に鍵が復元・悪用された証拠は把握していないと説明しています。10月23日時点で、実際の被害の報告は当社が確認した範囲では見当たりません。[1][2][3][6]
では、何をすればよいのですか？
いまは「更新が届いているか」を確かめる段階です。院内のパソコンとスマートフォンのOSとブラウザを更新して再起動し、確認サイトで安全側になっていることをブラウザごとに確かめます。電子カルテや予約システムなど保守事業者が管理するシステムは、文書で問い合わせます。パソコンに自分で入れたJavaがあれば、自動更新を待たず、提供元から最新版を取得して更新し、Oracleが案内する追加の手順まで行います。手順は02章、文例は05章にあります。
Windows 10のEdgeは、10月20日時点でまだ遮断されていなかったと報道され、その後の状況をMicrosoftは説明していません。Apple製品の遮断は、確認サイトの記載では22日で、他社より遅れました。スマートフォンでは、LINEなどのアプリから開く「アプリ内ブラウザ」や、Samsung Internetなど端末メーカーのブラウザが、Chromeとは別に問題の証明書を信じたままの例が、確認サイトの統計にも当社の端末でも確認されています（02章の手順2の補足）。いずれも「自動更新だから大丈夫」と考えず、確認サイトで確かめてください。[6][8][12]
やること（優先順に4つ）
対策は各社が自動で配っています。端末がインターネットにつながり、電源が入っていることが条件です。OSとブラウザの更新は、保守事業者に頼む作業ではなく、医療機関自身が更新状況を確かめて進める作業です。保守事業者が管理している端末は、その事業者の手順に従ってください。更新して再起動し、確認サイトで確かめるまでを1セットにしてください。
手順1 OSとブラウザを更新して再起動する（今日中）
| 機器 | 操作 |
|---|---|
| Windows 11 | 「設定」→「Windows Update」→「更新プログラムのチェック」。終わったら再起動。 Edgeは右上「…」→「ヘルプとフィードバック」→「Microsoft Edge について」で更新。Chromeは右上「⋮」→「ヘルプ」→「Google Chrome について」。 |
| Windows 10 | 「設定」→「更新とセキュリティ」→「Windows Update」→「更新プログラムのチェック」。ブラウザは上と同じ。手順2の確認を必ず行ってください。 |
| macOS | Appleメニュー→「システム設定」→「一般」→「ソフトウェアアップデート」。SafariはmacOSと一緒に更新されます。 |
| iPhone・iPad | 「設定」→「一般」→「ソフトウェアアップデート」。 |
| Android | まず端末を再起動します（Googleは、再起動で保護が即時に適用されると案内）。次に「設定」→「システム」→「システムアップデート」（メーカーにより表記が異なります）。Chromeは「Playストア」から更新。Firefoxは158.0.2以上にしてください。[1][2] |
Windowsの遮断は、Windows Updateとは別の「信頼しない証明書の一覧」の自動配信で届きます。閉域網やオフラインで使うパソコン、自動配信を止めている管理端末には届かないので、そのパソコンはそれを管理している事業者や担当者に確認してください。情報担当の方は、管理者権限のコマンドプロンプトで certutil -verifyctl Disallowed | findstr /i lastsynctime を実行すると、一覧を最後に受け取った日時が分かります。サポートが終了したWindows 7では、更新プログラムKB2677070が入っている場合にだけこの自動配信が働くと、Microsoftの文書にあります（Windows 8.1には組み込まれています）。サポート終了後のWindowsに今も届くかどうかは、Microsoftの文書にありません。[6][7][18]
手順1の補足 チャット・メモなどのデスクトップアプリも更新する
Slack・Chatwork・Discord・Notion・Visual Studio Codeなど、「Electron」という仕組みで作られたデスクトップアプリは、ブラウザとは別に、アプリ自身の更新が必要です。ElectronはChromeの遮断リストを受け取らないため、10月20日に公開された修正版のElectronを取り込んだアプリの更新で初めて遮断されます。各アプリを最新版にしてください。更新が届くまでは、公衆Wi-Fiや無料VPNなど信頼できない回線でこれらのアプリを使わないでください。[6][13]
手順2 確認サイトで、ブラウザごとに確かめる
https://emudhra.we-have-a-problem.com/
Mozillaの暗号技術者 Dennis Jackson 氏が公開し、コミュニティが寄稿しているサイトで、ソースコードはGitHubで公開されています。CloudflareとUbuntuの公式ブログも参照しています。サーバ側に記録されるのは、接続できたブラウザの種類ごとの回数だけと明記されています。[4][5][6]
ページを開くと、中ほどの表が自動で14行の検査を始めます（「Run again」で再実行）。普段使うブラウザごとに開いてください。
| 表示 | 意味と、次にすること |
|---|---|
| Did not connectが全行 | 安全側です。表の下に「Your browser trusted 0 of 14 compromised certificate chains.」と出ます。通信障害でも同じ表示になるため、確認サイト自身は「✅は接続が失敗したことだけを意味する。念のため各行のリンクを開き、警告なしにページが表示されたら、そのブラウザはまだ危険」と案内しています。[6] |
| Insecureが1行でも | そのブラウザはまだ問題の証明書を信じています。手順1をやり直して再起動してください。Windows 10のEdgeで消えない場合は、Microsoftの更新が届くまで、更新済みのChromeかFirefoxを使ってください。この2つはWindowsとは別の仕組み（CRLSet・OneCRL）で遮断しています。[1][2][8] |
| Inconclusive | 判定不能です。回線が遅いときや、院内のUTMなどがHTTPS通信を途中で検査しているときに出ます。安全の証拠にはならないので、時間をおいて再実行するか、別の回線（スマートフォンのテザリングなど）で試してください。 |
表示の意味は確認サイトの記載による。[6]
同じ端末の他のソフトや、院内の機器が安全とは限りません。それは手順3で確かめます。また、URLは手入力で正確に。確認ツールを名乗る偽サイトへの注意が報じられています。[4][6][11]
手順2の補足 アプリ内ブラウザと、端末メーカーのブラウザも確認する
LINE・LINE WORKS・Xなどのアプリからリンクを開いたときに使われる「アプリ内ブラウザ」と、Samsung Internetなど端末メーカーのブラウザは、Chromeとは別の仕組みで証明書を検証しています。確認サイトの統計には、10月23日時点でこれらからの接続（まだ問題の証明書を信じている、という意味）が多数記録されています。[12] 当社のAndroid端末でも、10月23日に、業務チャットアプリから開いたアプリ内ブラウザはほとんどの行がInsecure、Samsung InternetはOSを更新した後も14行中7行がInsecureでした（Galaxy S24 FE）。別のGalaxy（A23）では14行すべてがInsecureでした。
対処は次の順です。端末を再起動してOSとアプリを更新し、再確認する。それでもInsecureが残るブラウザは使わず、アプリ内のリンクはメニューの「ブラウザで開く」「他のアプリで開く」でChromeに渡し、メーカーのブラウザの代わりにChromeを使う。iPhoneでも、アプリ内ブラウザで確認サイトを開いて確かめてください。
手順3 保守事業者が管理するシステムは、文書で問い合わせる（今週中）
電子カルテ・レセコン・予約システム・VPN装置・複合機などは、OSの更新だけでは直らないことがあります。独自の証明書の一覧を内蔵するソフト（Java製など）は個別の更新が必要だと、各社が揃って述べています。判断の目安は04章、文例は05章にあります。[4][5][6]
手順3の補足 Javaで動くソフトは、Java側の対応が必要です
Javaは、配布元と証明書の一覧の構成によって対応が異なり、OSやブラウザの更新だけでは完了しない場合があります。Windowsに入れたOracleのJavaは、Java自身の証明書の一覧を使うので、Java側の対応が必要です。Javaの提供元であるOracleとOpenJDKは10月21日に、問題の証明書を信頼しない修正版を公開しました。ただしOracleは10月23日に、修正版に更新済みであっても、Javaを再起動する前に、関連するルート証明書2本の削除か失効確認の有効化のどちらかを行い、複数のJavaが入っていればそれぞれに行うよう、本件専用のページで案内しています。最新版への更新だけで完了と判断せず、この追加対応と再起動、問題の証明書を拒否することの確認までを対応の範囲としてください。誰が対応するかは、そのJavaを誰が入れたかで決まります。[14][15][16][22]
- 医療機関が自分でパソコンに入れたJava（java.comから入れたものなど）は、医療機関の責任で対応します。自動更新を待たず、Javaの提供元から最新版を取得して入れ直したうえで、Oracleの本件専用の手順（ルート証明書2本の削除、または失効確認の有効化。その後Javaを再起動）を行ってください。Javaのコマンド操作になるので、院内で難しければ、IT担当者や依頼できる事業者に頼んでください。入っているJavaとその版は、Windowsの「設定」→「アプリ」で確認できます。[22]
- 業務ソフトに同梱されたJavaや、保守事業者が入れたJavaは、その事業者の作業です。製品がJavaを使っているかどうかを保守事業者に確認し、使っていれば、修正版への更新・Oracleの追加対応・再起動・拒否の確認までを速やかに行ってもらってください（05章の文例2〜4）。
- 日医標準レセプトソフトは、現在はすべてWebORCA（クラウド・オンプレ）になっており、Javaのクライアントは存在していないことになっています。何らかの理由で、旧Ginbeeをお使いのところは、自らJavaの更新を行う必要があります。
- オンライン請求システムをMacで使っている医療機関は、審査支払機関のセットアップ手順（令和8年10月版）でOracle製Javaを入れています。これは自分で入れたJavaにあたります。Windows・Linuxの区分には、手順にJavaのインストールはありません。[17]
手順4 証明書の警告が出ても回避せず、記録して連絡する（継続）
更新後に特定のサイトで証明書の警告が出ても、「続行」や検証の無効化で乗り越えないでください。Chromeは10月27日に、問題の認証局を署名したルート証明書そのものを削除する予定で、そのルート配下にある正規のサイトは別の証明書への差し替えが必要になります。そのルート配下の証明書を使い続けているサイトはChromeで開けなくなりますが、それはそのサイト側の証明書の問題です。画面写真を撮って、そのサービスの事業者に連絡してください。[1][4]
「HTTPSの暗号が破られた」のではなく、「相手が本物か」を証明する仕組みの一部に穴があいた
Webサイトを開くと、ブラウザは「このサイトは本物だ」と保証する電子証明書を確かめます。証明書を発行するのが認証局（CA）で、どの認証局を信頼するかの一覧をOSとブラウザが持っています。今回は、認証局の一つeMudhraが持つ8本の中間CA証明書の秘密鍵が、鍵を作るときの乱数が不十分だったために第三者に導き出せる状態だった、という問題です。[1][3]
鍵を手にした者は、まだこの中間CAを信頼している端末に対して、どんなWebサイトにもなりすます証明書を作れます。ただし実際に通信を盗み見るには、偽の証明書に加えて、その端末の通信経路に割り込む必要があります。[1][2][8]
TLS/HTTPSの暗号方式が解読されたわけではありません。対策は、問題の証明書を信頼しないようにすることです。各社は、ブラウザやOSが持つ「信頼しない証明書の一覧」を更新して対応しました。[1][2][4]
安心してよい点と、まだ分からない点
- Googleは、遮断前の時点でこれらの中間CAに連なるTLS証明書は Certificate Transparency（公開の証明書台帳）に一件も記録されておらず、台帳への記録を必須とするChromeなどに対しては偽の証明書は使えなかった、と説明しています。[1]
- eMudhraは、8本から利用者向けの証明書は一度も発行していない、開示前に鍵が復元・悪用された証拠は把握していない、影響は米国の一顧客の範囲に限られる、と説明しています（発行元自身の説明です）。[3]
- Cloudflareは、自社サービスで能動的な悪用を確認していないとしています。[4]
- 一方で確認サイトは、ブラウザ以外の多くのソフトは台帳への記録を必須としておらず、そうしたソフトが狙われたかどうかは分からない、としています。[6]
時系列（要約）
- 10月17日報告
- 10月18日
eMudhraが8本の中間CA証明書を失効
発行元自身の説明です。[3]
- 10月19日
AndroidにGoogle Play開発者サービス経由で配信
再起動で即時に適用されます。[1]
- 10月20日公表
- 10月21日
- 10月22日
- 10月22日
eMudhraが、世界向けのSSL/TLS証明書事業からの撤退を発表
発行元自身の発表です。既存の証明書は提携先の証明書へ無償で置き換え、失効情報の提供は置き換えが終わるまで続けるとしています。[21]
- 10月27日予定
Chromeが、問題の認証局を署名したルート証明書を削除
そのルート配下の正規サイトは、別の証明書に差し替えが必要になります。[1]
国内では、JPCERT/CC・IPA・NISCからの注意喚起は10月24日時点でも確認できていません（当社確認。JPCERT/CCの10月21日付Weekly Reportにも項目がなく、IPAの10月21日付のOracle Javaの注意喚起は証明書に触れていません）。ITmedia・PC Watch・窓の杜などが報じています。[9][10][11]
院内のシステムは関係があるか
本資料は主に、インターネット上のサイトやサービスにHTTPSで接続する側の端末とソフトを扱います。医療機関が持つものを、この前提で分けます。保守事業者・IT担当者向けには、言語ランタイム・アプリ・ネットワーク機器・国内各社の公式な対応状況を当社が10月24日に照合したベンダー・ソフト別の対応状況を別ページにまとめています。
| システム | 判断 | 理由と確認先 |
|---|---|---|
| 院内のWindows・Macのパソコン（ブラウザ利用） | 対象になりうる 02章の手順1・2で完了 | ブラウザ各社とOS各社が遮断を配信済みで、更新と確認は医療機関自身で行います。閉域網やオフラインのWindowsパソコン（ベンダー管理の端末など）には自動配信が届かないので、その端末を管理している事業者に確認します。[1][2][6][7] |
| スマートフォン・タブレット | 対象になりうる 更新と再起動のあと確認 | Androidは19日に配信され、再起動で即時に適用されます。iPhone・iPadはAppleが証明書設定を配信しますが、遮断は確認サイトの記載で22日と他社より遅かったので、実機で確認します。[1][6] |
| スマートフォンのアプリ内ブラウザ・端末メーカーのブラウザ | 対象になりうる 更新後も残るならChromeを使う | Chromeとは別の仕組みで検証します。確認サイトの統計と当社の端末で、10月23日時点で未遮断の例を確認しました。02章の手順2の補足。[12] |
| チャット・メモなどのデスクトップアプリ（Slack・Chatworkなど） | 対象になりうる 対策版への更新を確認 | Electron製はアプリ自身の更新が必要です。更新の有無は各アプリの提供元の案内で確認します。02章の手順1の補足。[6][13] |
| 電子カルテ・レセコン・予約システム（保守事業者が管理） | 保守事業者に確認 | 公開された一次資料はこれらに言及していません。一般に、独自の証明書の一覧を内蔵するソフト（Java製など）はOSの更新では直らず、個別の更新が要ります。Javaの修正版は10月21日に公開済みですが、Oracleは更新後もルート証明書の削除か失効確認の有効化と再起動を求めています。製品がJavaを使うかを保守事業者に確認し、使っていれば、更新と追加対応と拒否の確認までを速やかに求めてください。[4][5][6][14] |
| 医療機関が自分でパソコンに入れたJava | 対象になりうる 医療機関自身で更新 | java.comなどから自分で入れたJavaは、医療機関の責任で対応します。自動更新を待たず、提供元から最新版を取得して入れ直し、Oracleの本件専用の手順（ルート証明書2本の削除か失効確認の有効化、再起動）まで行います。02章の手順3の補足。[14][22] |
| 日医標準レセプトソフト（WebORCA） | 端末側は02章の手順1・2で完了 | 現在はすべてWebORCA（クラウド・オンプレ）で、Javaのクライアントは存在していないことになっています。端末はブラウザで利用する構成なので、端末側の対応は手順1・2です。サーバ側や周辺システムとの連携は、それぞれの提供元・保守事業者の対応によります。何らかの理由で、旧Ginbeeをお使いのところは、自らJavaの更新を行ってください。 |
| VPN装置・ルータ・複合機 | 保守事業者に確認 | 機器が外部とHTTPSで通信する機能（クラウド連携・自動更新・遠隔保守など）を持つかどうかは、保守事業者でないと分かりません。10月24日時点で公式の案内を出しているのは、Cisco（10月23日。Secure Client〔旧AnyConnect〕とMeraki vMXは調査中、Meraki Dashboard・ASA・FTDは影響あり。案内に載っていない製品は影響なしと明記）と、Fortinet（FortiGateのFortiGuardへの接続は専用のCA一覧を使うため影響なし。ただしSSL検査に使う信頼CAの一覧には問題のルートが残り、別途、設定での無効化が要る）です。国内のルータ各社（Yamaha・NEC・Buffalo）と複合機各社（Ricoh・Canon・Fujifilm・Konica Minolta・Kyocera・Sharp・Brother・Epson）の公式情報は、当社が確認した範囲では見当たりません。[19][20] |
| クラウドサービス（メール・会計・Web会議など） | 利用者側は手順1・2で完了 | サービス側の対応は提供事業者の責任です。10月27日以降にChromeで開けなくなるサービスがあれば、その事業者の証明書の問題です。[1][4] |
保守事業者への問い合わせ文例と、回答の読み方
電子カルテ・レセコン・予約システムなどの提供元や保守事業者に、そのまま送れる文例です。〇〇の部分を書き換えてお使いください。問い合わせの際は、保守事業者・IT担当者向けのベンダー・ソフト別の対応状況（当社確認 10月24日）もあわせてお渡しください。
件名：eMudhra 中間CA証明書問題（2026年10月公表）への対応状況の確認
いつもお世話になっております。〇〇クリニックの〇〇です。
2026年10月に公表された、認証局 eMudhra の中間CA証明書8本の秘密鍵の問題
（Google・Mozilla・Apple・Microsoft が遮断済み）について、貴社ご提供の
〇〇（製品・サービス名）に関し、以下をご回答ください。
1. 当院で利用中の製品・サービス（サーバ側・端末側・外部連携を含む）に、
今回の件の影響はありますか。
2. 影響の調査は、製品本体だけでなく、製品に同梱されたランタイム
（Java・Electron・Node.js・Python など）、通信ライブラリ、CA バンドルまで
含めて行いましたか。また、サーバ・端末・コンテナ・外部 API 連携など、
実際に外部と HTTPS 通信している処理まで確認しましたか。
3. 更新が必要だった場合、ファイルの更新だけでなく、稼働中のサービスへの
反映（再起動・再配布・イメージの更新）まで完了していますか。
完了していれば適用日と版、未完了なら予定日をお知らせのうえ、
速やかな更新をお願いします。Java については 2026年10月21日に
Oracle・OpenJDK が修正版（Java 8 は 8u511 b32、11 以降は 11.0.33.0.2・
17.0.21.0.2・21.0.13.0.2・25.0.5.0.2・27.0.1.0.2、または各配布元の相当版）を
公開していますが、Oracle は 10月23日に、修正版に更新済みでも再起動前に
関連ルート証明書の削除か失効確認の有効化を行うよう案内しています。
更新に加えてこの追加対応と再起動まで完了しているかをお知らせください。
4. 更新後に、その製品自身の証明書検証の経路で、問題の証明書を拒否することを
確認しましたか。ブラウザや curl での確認は、製品の確認の代わりになりません。
5. 貴社が管理している当院の端末について、インターネットにつながらない
閉域網のものには Windows の自動配信が届きません。「信頼しない証明書の
一覧」の更新は貴社で実施いただけますか、当院側の作業が必要ですか。
6. 更新後に証明書の警告が出た場合の連絡先を教えてください。
証明書の検証を無効にする回避は行わない方針でよろしいですか。
7. 本対応は保守契約の範囲内でしょうか。
お手数ですが、〇月〇日までにご回答をお願いいたします。回答の読み方
「影響なし」「対応済み」に根拠が添えてあるかを見ます。見るのは3つです。調べた範囲（製品本体だけか、同梱のランタイムや通信ライブラリ、CAバンドルまで見たか）、反映の完了（更新した版と日付、再起動や再配布まで済んだか）、製品自身での確認（その製品の証明書検証の経路で、問題の証明書を拒否することを確かめたか）。製品名と「対応済み」だけの回答は、この3つをもう一度たずねてください。Javaを使う製品なら、更新後のJavaの版（8u511 b32、11.0.33.0.2 など）に加えて、Oracleの追加対応（ルート証明書の削除か失効確認の有効化）と再起動が済んでいるかも見ます。この3つは、Cloudflareが自社の対応として説明している範囲と同じです（同梱や独自の信頼ストアを持つアプリは別に評価して更新する、更新には再起動や再配備を伴わせる、実際のTLSの経路で検証する。ブラウザでの確認はバックグラウンドのサービスの安全を証明しない）。[4]
やってはいけないこと
当社の対応と、医療機関の皆さまへのお願い
当社の公開サイト（www.jmedic.co.jp）の証明書は、本件の認証局が発行したものではありません。これはサイト側の事実であり、閲覧する端末や業務ソフトの側に影響がないことを意味するものではありません。
一方、各医療機関の端末や業務システムは、それぞれの保守事業者が管理しており、当社がその構成を把握する立場にはありません。院内のパソコンとスマートフォンは02章の手順で確認し、電子カルテや予約システムなど保守事業者が管理するシステムは、05章の文例でそれぞれの保守事業者にお問い合わせのうえ確認してください。
当社保守のお客様は、更新方法が分からない場合や回答の読み方に迷う場合、お問い合わせフォームからご相談ください。保守契約のない医療機関の皆さまからの個別のお問い合わせは受けかねますが、公開できる情報は本資料やお知らせで発信していきますので、そちらを参考にしてください。
本件は、先にご案内したPHPの重大脆弱性とはまったく別の事案です。PHPで動くWebサイトを持つ医療機関は、PHP2Shell の解説資料もあわせてご確認ください。
出典と、確認できた範囲
本文は、以下の公式告知・確認サイト・報道を2026年10月23日に確認して作成し、出典14以降は10月24日に確認して追記しました。発表主体自身の説明は、独立した第三者による事実認定とは区別しています。リンク先が後日更新されると、本資料の記載と差が出る場合があります。
- Google Security Blog：Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates2026-10-20付。報告の受領（10月17日）、鍵生成時の乱数不足、CRLSetによる遮断、Androidへの配信と再起動、CTログに記録が無かったこと、10月27日のルート削除予定。
- Mozilla Security Blog：Protecting Firefox users following the compromise of eMudhra intermediate certificates2026-10-20付（21日追記）。OneCRLによる同日遮断、Firefox for Android 158.0.2。
- eMudhra：Statement on Recent Certificate Security Incident初版2026-10-20・更新10-22。8本の失効（10月18日）、利用者向け証明書の発行実績なし、悪用の証拠なし、影響範囲の説明。発行元自身の説明。
- Cloudflare Blog：8 eMudhra certificates are compromised. Here's what you need to know2026-10-20付（21日更新）。暗号方式の問題ではないこと、能動的な悪用を確認していないこと、ブラウザの確認結果は他のソフトの安全を証明しないこと、検証を無効化しないこと、確認サイトへの言及。
- Ubuntu：eMudhra CA compromise fixes available2026-10-20付（22日更新）。ca-certificatesの修正版、Javaなど独自の証明書一覧を持つソフトの個別対応、確認サイトへの言及。10-22更新で、Ubuntu配布のOpenJDKはシステムのルートストアを使うため影響なしだが、別の不具合でJava側のストアの同期が止まっており手動で再生成が必要と明記。
- eMudhra Intermediate CA Compromise（確認サイト）Dennis Jackson氏（Mozilla）が公開、コミュニティ寄稿、ソースはGitHubで公開。各社の遮断日、検査結果の表示の意味、Windowsの自動配信、ソフト別の修正版一覧、回避手順の注意書き。遮断日の記載は10月22日に改訂されている。
- Microsoft Learn：Configure trusted roots and disallowed certificates in WindowsWindowsの「信頼しない証明書の一覧」が自動配信される仕組みと、切断環境での扱い、certutilでの確認方法。本件固有の告知ではない。
- Ars Technica：The Internet goes on high alert after discovery of 8 compromised TLS certs2026-10-20付。公表時点でWindows 10のEdgeが未遮断だったこと、Microsoftの回答、悪用には通信経路への介入が要ること。
- ITmedia NEWS：認証局eMudhraの中間証明書、秘密鍵が「数ミリ秒」で復元可能な脆弱性 大手各社が緊急遮断2026-10-21付（22日更新）。国内での第一報。
- PC Watch：本来116桁の秘密鍵がたった3桁 インド認証局の一部中間CA証明書にミス2026-10-22付。各社の遮断開始日の報道（確認サイトの当時の記載を引用）。
- 窓の杜（やじうまの杜）：PHPの影に隠れたもう一つの重大インシデント「eMudhra」の証明書問題、どう対処すれば？2026-10-22付（23日更新）。OSやブラウザの対応状況の整理、確認サイトの読み方、偽の確認ツールへの注意。
- eMudhra Intermediate CA Compromise 確認サイト：接続統計（user-agent別）確認サイトのサーバに記録された「接続できてしまった（まだ問題の証明書を信じている）」クライアントの件数。2026-10-23 17:35（日本時間）に取得した直近24時間分で、Samsung Internet、Androidのアプリ内ブラウザ、iPhoneのアプリ内ブラウザ、Edge on Windowsなどからの接続が多数。自動化ツールや各社の修正前の記録も含む。
- Electron v44.9.1 リリースノート2026-10-20付。「侵害されたeMudhra中間証明書への緩和策（GHSA-jr5w-w6x2-84p9）を含む」と明記。修正のPR #55126に、ElectronはChromeのCRLSetを受け取らないとの説明。43.8.1・42.11.16にも同じ修正。
- Oracle Security Alert Advisory - CVE-2026-914032026-10-21付。eMudhra関連の中間CA証明書を信頼しないJavaの更新。対象はOracle Java SE 8u511・11.0.33・17.0.21・21.0.13・25.0.5・27.0.1とGraalVM。最新版への更新か、緩和策（ops.java/emudhra）の適用を案内（Rev 1）。サポート外の旧版は未検証で、Oracleはサポート版への更新を推奨。専用ページ（出典22）は10-23更新で、更新後も追加対応を求めている。
- Oracle：JDK 8u511 b32 Release Notes2026-10-21付。eMudhraの中間CA証明書8本とSectigoによるクロス署名8本を遮断リスト（blacklisted.certs）に追加。その鎖を含むTLS接続は成立しない。
- OpenJDK Vulnerability Advisory: 2026/10/21CVE-2026-91403。単体のJavaランタイムは速やかに更新し、できない場合は遮断リストの差し替えか失効確認の有効化。OSに同梱のOpenJDK（Ubuntu・RHELなど）はOSの証明書更新で足りる。
- 医療情報基盤・診療報酬審査支払機構（旧 社会保険診療報酬支払基金）：オンライン請求システム再セットアップ方法（令和8年10月）区分E「医療機関・薬局（Mac）」にのみ「オラクル製Javaのインストール」の手順がある。Windows（区分A〜C）・Linux（区分D）の手順にJavaはない。
- Microsoft：KB2677070 An automatic updater of untrusted certificates is available for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2この更新プログラムを入れたWindows 7等で「信頼しない証明書」の自動更新が働く。切断環境には効果がない。Windows 8/8.1・Server 2012には同じ機能が組み込まれている（Microsoft Learn、出典7）。
- Cisco Security Advisory（Informational）cisco-sa-emudhra-info-ScS22A1r2026-10-23付（Interim）。Secure Client・Meraki vMXは調査中、Meraki Dashboard・Secure Firewall ASA・FTDは影響あり・調査継続、FMCは手順あり、Duo DAG 3.2.0・DNG 3.4.1は修正版。本勧告に載っていない製品は影響なしと明記。悪用は未確認。
- Fortinet Community（Technical Tip）：How to protect endpoints affected by eMudhra Certificate Authority compromise2026-10-21付。FortiGateのFortiGuard接続は専用のCAリストのため影響なし。SSL検査の信頼CAにemSign ECC Root CA - G3がCertificate Bundle 1.00064以下で残り、手動削除は不可、CLIで無効化。AAA Certificate ServicesはFortiOSに未収録。
- eMudhra：eMudhra to Exit global SSL/TLS Certificate Business2026-10-22付。取締役会が世界向けSSL/TLS証明書事業からの自主的な撤退を決定。既存の証明書は提携先発行の証明書へ無償で置き換え、失効情報の提供は置き換え完了まで継続、根本原因の報告書をルートプログラムへ提出予定。発行元自身の発表。
- Oracle：Distrusting eMudhra Intermediate Certificates in Oracle JDK（ops.java/emudhra）2026-10-23更新。27.0.1.0.2／25.0.5.0.2／21.0.13.0.2／17.0.21.0.2／11.0.33.0.2／8u511 b32に更新済みであっても、JVMを再起動する前に、ルート証明書2本（emSign ECC Root CA - G3、AAA Certificate Services）の削除か、失効確認の有効化のどちらかを行う。稼働中のインスタンスは再起動し、複数の単体Javaがあればそれぞれに行う。確認用プログラム CheckCerts.java を提供。
確認できていないこと
- AppleとMicrosoftの公式発表（遮断日は確認サイトと報道による）。
- Windows 10のEdgeが、10月20日以降に遮断されたかどうか。
- 国内の公的機関（JPCERT/CC・IPA・NISC）からの注意喚起（10月24日時点で見当たらず）。
- 電子カルテ・レセコン・VPN装置などへの個別の影響（一次資料に言及なし）。VPN装置は製品により確認状況が異なる（Cisco・Fortinetは公式の案内あり、国内各社は見当たらず。04章）。
- Samsung Internetとアプリ内ブラウザに対する各社の修正配布の時期（Samsungの表明は見つからず）。
- Electron製の各デスクトップアプリが修正版を配布済みかどうか（アプリごとに異なる）。
- Javaの配布元のうち、Eclipse TemurinとMicrosoft Build of OpenJDKの対応表明（10月24日時点で、当社が確認した範囲では見当たらず）。
- 業務ソフト各社が同梱するJavaの更新状況。
- 国内の電子カルテ・レセコン・クリニック向けクラウド各社（12社）の公式告知での言及（10月24日時点で見当たらず）。
- 国内のルータ各社と複合機各社、Zoom・Teams・Slack・Chatwork・LINE WORKS・LINEなどの公式声明（10月24日時点で見当たらず。修正版Electronの取り込みを明記しているのはObsidianのみ）。
本資料は、各社の公式告知と確認サイトを2026年10月23日に照合して作成した注意喚起です。作成には生成AIを調査・下書き・出典照合に使用し、公開前の内容確認は当社が行いました。攻撃の再現や第三者システムへの検証は実施していません。公開後の同日に、02章・04章・05章の確認先の記述を修正しました（OSとブラウザの更新は医療機関自身の作業であること、保守事業者への確認はその事業者が管理する製品・端末に限ること）。同日夜に、スマートフォンのアプリ内ブラウザと端末メーカーのブラウザ、Electron製デスクトップアプリに関する記述を追加しました（01章・02章の手順1と手順2の補足・04章・出典12〜13）。本資料は公開後も各社の告知の確認を続け、追加で分かったことは日付を付けて追記します。10月24日に、Javaの修正版（Oracle・OpenJDKが10月21日に公開）について確認した内容を追記しました（01章・02章の手順3の補足・03章の時系列・04章・05章の文例2と回答の読み方・出典14〜16・確認できていないこと）。同日に2回目の追記として、保守事業者への問い合わせ文例を「調べた範囲」「反映の完了」「製品自身での確認」の3点で具体化し（Cloudflareの説明に合わせました）、オンライン請求（Mac）のJava、Windows 7の自動配信の条件、VPN装置のベンダー公式案内（Cisco・Fortinet）、eMudhraの事業撤退の発表、国内の確認状況を追記しました（02章の手順1の囲みと手順3の補足・03章・04章・05章・出典17〜22・確認できていないこと）。あわせて、JavaはOracleの10月23日の案内に従い「修正版への更新だけでは完了しない」趣旨に改め、確認サイトの「Did not connect」の留保、Fortinetの影響範囲の限定、日付の基準の明記、冒頭の「報告」と「公表」の区別、実行主体の表現を直しました。あわせて、保守事業者・IT担当者向けの別ページ「ベンダー・ソフト別の対応状況（当社確認 2026年10月24日）」を公開し、04章と05章からリンクしました。