認証局eMudhraの中間証明書8枚の秘密鍵が漏れた。テスト用サイトによればブラウザは遮断済みで、残るのはブラウザの外の通信 ── 自社と担当サイトの信頼の経路を確かめる13項目（2026年10月時点）

目次

1. 01 何が書いてあるか — 認証局eMudhraの中間証明書8枚の秘密鍵が漏れた。テスト用サイトによればブラウザは遮断済みで、残るのはブラウザの外の通信
   1. Cloudflareが2026年10月20日に書いたこと
   2. もう1つの出典 — テスト用サイトに書かれたこと
   3. 時系列の表
2. 02 なぜ・背景 — 中間証明書の鍵が弱いと、信頼の鎖の途中から偽物を作れる
   1. 証明書の「鎖」と、中間証明書の役目
   2. テスト用サイトが書く原因
   3. 「ブラウザは対応済み」と「ほかは対応済み」は別
3. 03 この記事に出てくる用語
   1. 中間証明書
   2. 信頼リスト（トラストストア）
   3. 失効
   4. 証明書の透明性（CT）
   5. 相互TLS（mTLS）
   6. Full (strict)
   7. SDKの下を見る
4. 04 型別 — 通信の経路ごとに、信頼リストの持ち主を数える
   1. 🅰 適用範囲 — 誰が確かめるのか
   2. 🅱 公開された情報が測っていないこと
   3. 🅲 手順 — 経路ごとに、何を確かめるか
   4. ブラウザの確認では、サーバーの通信は証明できない
5. 05 明日、自社と担当サイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 信頼の置き場所を確かめる方法は1つではない
   1. Cloudflareを使っていない場合
7. 07 当サイトで確かめたこと — 証明書の発行元と、サーバー同士の通信
8. 08 このテーマは、ここまで
   1. 2025年4月 — 中間証明書が作られた
   2. 2026年10月17日 — 報告とブラウザの遮断
   3. 2026年10月19日 — 開示とAppleの遮断
   4. 2026年10月20日 — Cloudflareの更新とブログ
   5. 2026年10月21日 — この記事の確認日
   6. この事故のあとの宿題
9. 09 この記事のまとめ

01 何が書いてあるか — 認証局eMudhraの中間証明書8枚の秘密鍵が漏れた。テスト用サイトによればブラウザは遮断済みで、残るのはブラウザの外の通信

Cloudflareが2026年10月20日に書いたこと

Cloudflareのブログ「8 eMudhra certificates are compromised. Here's what you need to know」（訳: eMudhraの証明書8枚が危うくなった。知っておくべきこと。2026年10月20日付）は、認証局eMudhraの中間証明書8枚について、秘密鍵が漏れたと書く。Cloudflareがそれを知ったのは、2026年10月19日の約17:00 UTC（日本時間では10月20日の午前2時ごろ）だという。

ブログは、この事故の重さを次の1文で書く。

"Because the keys themselves are weak, an attacker can create a forged certificate for any domain and use it to impersonate servers to intercept or modify traffic."

（訳: 鍵そのものが弱いので、攻撃者は任意のドメインの偽の証明書を作り、サーバーになりすまして、通信を横取りしたり書き換えたりできる。）

一方で、Cloudflare自身のサービスについては、次のように書く。

"Our security review has not identified active exploitation of this issue on Cloudflare services."

（訳: 私たちのセキュリティの確認では、この問題がCloudflareのサービスで実際に悪用された形跡は見つかっていない。）

この記事は、自社と担当サイトで、証明書の発行元と、通信の経路ごとの信頼の置き場所を確かめる手順を扱う。更新の日数や自動更新の話は、解説記事Let's Encryptの証明書は2027年2月10日から標準で64日になる ── 更新の設定の「日数の決め打ち」とARI対応を確かめる13項目（2026年10月時点）に、ドメイン確認の話はLet's Encryptのドメイン確認の使い回しは30日から10日に縮む。通常の更新は、寿命の約3分の2で動くなら毎回確認し直している計算になる ── 確認の方法が毎回通るかを自社で確かめる14項目（2026年10月時点）に譲り、ここでは繰り返さない。

もう1つの出典 — テスト用サイトに書かれたこと

Cloudflareのブログは、開発者向けの案内の中で、Mozillaの技術者Dennis Jackson氏の名前を挙げ、テスト用のサイトを紹介している。そのサイト（we-have-a-problem.com内のeMudhraのページ、2026年10月20日付）は、次のことを書く。

• 8枚の中間証明書の秘密鍵が漏れた。それらは、Mozilla・Microsoft・Apple・Chromeのルートプログラムが信頼するルートにつながっている。
• 最初の報告者は10月17日に、各ルートプログラムのチームへ報告した。
• FirefoxとChromeでは10月17日から、Appleの端末では19日から、Microsoftのプラットフォームでは20日から、これらの証明書が遮断されている。
• 認証局も、漏れた中間証明書を失効させた。

このサイトは第三者のページで、ブラウザ各社の発表そのものではない。この記事の筆者は、Mozillaのバグ票（題名は「Private key compromise of eMudhra Intermediate Certificates」）と、Mozillaの掲示板のスレッド（題名は「Compromised eMudhra Intermediate Certificates」）が存在することまでは確かめたが、それぞれの中身を読んで、遮断の日付を照らし直す作業はしていない。ChromeとMicrosoftとAppleの、各社自身の発表のページも、確かめた範囲では見つけられなかった。遮断の日付は、テスト用サイトの記述として読んでほしい。

時系列の表

Cloudflareのブログにある時系列と、テスト用サイトの日付を、1つの表に並べる。UTCの時刻は、日本時間に直した値を添えた。

02 なぜ・背景 — 中間証明書の鍵が弱いと、信頼の鎖の途中から偽物を作れる

証明書の「鎖」と、中間証明書の役目

ブラウザがサイトの証明書を信頼するかどうかは、サイトの証明書から、ブラウザやOSが持つ信頼リストのルート認証局まで、鎖がつながるかで決まる。ルートの鍵は、普段は厳重にしまわれる。そのため、日々の発行は、ルートが署名した中間証明書が受け持つ。サイトの証明書は、中間証明書の鍵で署名される。

したがって、中間証明書の秘密鍵を持つ人は、どのドメイン名の証明書でも、自分で署名して作れる。鎖はルートまでつながるので、信頼リストに中間証明書の遮断が反映されていない相手には、本物と同じに見える。Cloudflareのブログが「鍵が弱い」と書くのは、このことである。

テスト用サイトが書く原因

テスト用サイトは、原因について次のように書く。

"The private keys for the intermediate certificates were incorrectly generated by the CA. This means that anyone can recover them from the certificates."

（訳: 中間証明書の秘密鍵は、認証局によって正しくない形で作られていた。つまり、誰でも証明書から鍵を復元できる。）

さらに、これらの証明書は2025年4月に作られたこと、その期間に、これらの中間証明書の記録が証明書の透明性のログに無かったことも書く。透明性のログを必ず確認するクライアント（Firefox・Chrome・Edge・Safariなど）は、この方法の攻撃を受けられなかったはずだ、という読み方である。ただし、ブラウザの外には、透明性を確認しないクライアントが多い。サイトは、攻撃者がこの欠陥を使って、そうしたクライアントを狙ったかは分からないと書く。

「ブラウザは対応済み」と「ほかは対応済み」は別

Cloudflareのブログは、ブラウザの側を次のように書く。ブラウザの管理者は、スイッチ1つで直せた。アプリが1つで済むうえ、ほとんどのブラウザは、Chromeの「CRLSets」のような、素早く失効を伝える仕組みを持つからである。

これに対して、サーバー同士の通信は違う。言語や、OSや、コンテナの中の信頼リストは、ブラウザのように素早く更新される仕組みを持たない場合が多い。テスト用サイトも、失効の情報を使わないクライアントが多く、そうしたクライアントは、ソフトウェアの更新で、漏れた中間証明書を信頼しない形にする必要があると書く。この記事の中心は、この違いである。

通信の安全に関する似た確認は、AI Ronのブログの記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── Apache 2.4.69を、記事を公開したその日に上げるまでにもある。ソフトの更新の知らせを読んだ日に、自分の環境を数える流れは、今回と同じ型である。

03 この記事に出てくる用語

中間証明書

ルート認証局と、サイトのサーバー証明書の間に入る証明書をいう。ルートの鍵を守るため、日々の発行を受け持つ。今回は、この中間証明書の秘密鍵が漏れた。

信頼リスト（トラストストア）

どのルート認証局を信頼するかの一覧をいう。ブラウザ、OS、プログラミング言語の部品、コンテナのイメージが、それぞれ別に持つ場合がある。Cloudflareのブログは、共有の信頼リストやベースイメージを更新したと書く。

失効

発行済みの証明書を、期限の前に使えなくすることをいう。Chromeは、緊急時に証明書をすばやく遮断するために、CRLSetsという一覧を使う。Chromiumのページによれば、ChromeはOCSPやCRLの確認を、通常は行わない。企業の設定で有効にできるのは、OCSPの確認である。

証明書の透明性（CT）

発行された証明書を、公開のログに記録する仕組みをいう。テスト用サイトは、今回の中間証明書にその期間の記録が無かったことから、透明性を確認するクライアントは攻撃を受けられなかったと読む。

相互TLS（mTLS）

サーバーだけでなく、クライアントも証明書を示し、双方を確かめる方法をいう。Cloudflareのブログは、利用者が設定したクライアント証明書の確認について、信頼リストやアップロードした認証局を見直すよう求める。

Full (strict)

CloudflareのSSL/TLSの暗号化モードの1つで、中継のCloudflareが、オリジンサーバーの証明書を厳しく確かめる。Cloudflareのドキュメントによれば、オリジンの証明書は、期限内であり、公に信頼された認証局かCloudflareのOrigin CAが発行し、名前が合っている必要がある。

SDKの下を見る

Cloudflareのブログが開発者向けに使う言い方である。通信の部品（SDK）が、証明書の確認を、HTTPライブラリ・言語の実行環境・OS・独自の設定のどれに任せているかを見る、という意味で使われる。

04 型別 — 通信の経路ごとに、信頼リストの持ち主を数える

🅰 適用範囲 — 誰が確かめるのか

この事故は、Cloudflareを使っている人だけの話ではない。サイトを持つ人は、次の3つのどれかで関係しうる。

• 自社のサイトの証明書の発行元が、eMudhraの鎖につながる場合。この確かめ方は、05章の1〜4番目にある。
• サイトのプログラムが、外部のAPI（決済・メール・SMS・計測・地図など）を呼ぶ場合。呼ぶ側のサーバーの信頼リストが古いと、偽の証明書を見分けられないことがある。
• 運営の端末・VPN・ビルドの環境が、更新されていない場合。担当者のパソコンや、納品物をつくる環境も、通信を行う。

ログインや会員登録の画面を持つサイトは、通信に載るのが、パスワードや個人情報である。通信が横取りされたときの影響は、ブログだけのサイトより重い。ただし、訪問者のブラウザが遮断済みなら、訪問者の側の通信は守られている。運営者が自分で確かめるのは、サーバーが出ていく側の通信である。

🅱 公開された情報が測っていないこと

Cloudflareのブログも、テスト用サイトも、次の点は書いていない。

• 8枚の中間証明書から、実際にサイトの証明書が発行された数と、そのサイトの一覧は、この記事の筆者が読んだ範囲では見つからなかった。
• 日本のサイトが影響を受けるか、受けないかは、どちらのページにも書かれていない。「日本のサイトは影響しない」とは言えない。言えるのは、自分の証明書の発行元と、自分の通信の経路を確かめれば分かる、ということである。
• 悪用の形跡は、Cloudflareは、自社のサービスでは見つけていないと書く。テスト用サイトは、悪用されたかは分からないと書く。どちらも、ブラウザの外の全体を見た数字ではない。

🅲 手順 — 経路ごとに、何を確かめるか

次の表は、通信の経路ごとに、確かめる場所と、直し方の型をまとめたものである。根拠にしたのは、Cloudflareのブログの「顧客がすること」の表と、テスト用サイトの記述である。

ブラウザの確認では、サーバーの通信は証明できない

Cloudflareのブログは、確かめ方についても、次のように書く。

"A successful browser test does not prove that a background service is protected."

（訳: ブラウザでのテストが通っても、裏で動くサービスが守られていることの証明にはならない。）

ブログは続けて、curlのテストも、そのアプリケーションが別の確認の部品を使っているなら、証明にならないと書く。確かめるのは、そのアプリケーションが実際に使う通信の経路でなければならない。「0件」や「通った」は、使った方法の範囲の結果でしかない。この点は、AI Ronのブログの「0件」は安心ではない、「N件」は危険ではない ── 同じ1日に、サイトを調べる針が両方向に倒れたと同じである。

05 明日、自社と担当サイトで確認できることチェックリスト

以下は、自社と担当サイトで、証明書の発行元と、サーバーが外へ出ていく通信の信頼の置き場所を確かめる13項目である。1〜4番目はサイトの証明書、5〜9番目はサーバーが外へ出ていく通信、10〜11番目は設定の見直し、12〜13番目は記録と次への備えである。1項目は5分以内でできる。チェックの状態はブラウザに保存され、サーバーには送られない。

• 担当サイトを3つ選び、ブラウザで開いて、鍵のマークから証明書の発行元の名前を読み、eMudhraやemSignの名前が無いか確認する
• 手順1の結果が、パソコンの通信を中継するウイルス対策ソフトの名前になっていないか確認し、なっていれば、別のパソコンかサーバーの中から、同じ確認をやり直す
• サーバーの中で openssl s_client の -showcerts を使い、3サイトの、サーバーが送る鎖の発行者の名前を書き出して、eMudhraの名前が含まれないか確認する
• 各サイトの証明書の契約書・請求書・管理画面の3か所を開き、発行元の認証局の名前を、一覧の1列に書く
• サイトのプログラムが外部のAPI（決済・メール・SMS・計測・地図など）を呼ぶ箇所を5つ書き出し、それぞれを動かす言語とOSの名前を横に書く
• サーバーの中から、テスト用サイトの12のホストのうち1つへ、curlで接続し、証明書の誤りで止まるかを確認する。止まらなければ、そのサーバーの信頼リストが古いと記録する
• 手順5で書いた言語ごとに、サイトのプログラムと同じ通信の部品を使って、手順6と同じ接続を1回ずつ試し、結果を書く
• テスト用サイトの修正版の表を開き、使っている言語と部品の3つについて、修正版の番号と自社の版の番号を並べて書く
• コンテナや配布用イメージを使っているなら、イメージを最後に作り直した日付を1件確認し、修正版が出た10月20日より後かを比べる
• 相互TLSや、Cloudflareのオリジン証明書の設定を使っているなら、管理画面で、信頼リストにある認証局の数と、アップロードした認証局の数を数える
• ソースの中で「verify=False」「-k」「rejectUnauthorized: false」など、証明書の確認を切る指定を3か所の検索で探し、見つかった本数を書く
• 各システムの更新を行った日時と、再起動か再読み込みを行った日時を、一覧に1行ずつ書く
• 次に同じ知らせが来たときに開く、システムの一覧・担当者・確認方法を1枚にまとめ、日付を入れる

3番目と6番目の確認の結果は、サイトの運営の記録に残す。セキュリティの状況を外から調べる道具として、当サイトの無料ツールの1つ、🔧 WEBサイトの外からできるセキュリティ対策監査ツールがある。ツールのページは、証明書・プロトコル・暗号スイートを含むSSL/TLSの分析を、調べる項目の1つに挙げる。会員限定のツールで、サインインして使う。このツールが、中間証明書の発行元の名前まで示すかは、ツールのページの説明からは分からない。

HTTPSでの接続や、セキュリティ用のヘッダーを、まとめて診断したいなら、🔧 WEBサイト総合分析・レポートツールも使える。ツールのページは、診断項目に、HTTPSへの対応とセキュリティヘッダー（HSTS・CSP・X-Frame-Options）を挙げる。証明書の発行元の名前は、診断項目として書かれていないので、発行元は1〜3番目の方法で確認する。

06 代替・他の選択肢 — 信頼の置き場所を確かめる方法は1つではない

サーバーの信頼リストを確かめる方法には、いくつかの選択肢がある。次の表は、公開されている情報から読み取れる範囲で、違いを並べたものである。

テスト用サイトは、更新を待てないときの回避策として、特定のルートを信頼リストから外す方法を、OSごとに載せている。ただし、一般の利用者には勧めない、専門の利用者向けの方法だと書く。この記事は、その手順を載せない。本番のサーバーで信頼リストを手で変えるときは、変更前の控えと、戻し方を先に用意する。

Cloudflareを使っていない場合

Cloudflareのブログの対策のうち、多くは、Cloudflareの製品を使う人向けである。使っていない人にとっては、ブログの「顧客がすること」の表は、そのまま当てはまらない。ただし、「SDKの下を見る」「検証を切らない」「再起動や作り直しまで済ませる」は、どの環境にも当てはまる。この記事の05章も、そうした部分に寄せて作ってある。

07 当サイトで確かめたこと — 証明書の発行元と、サーバー同士の通信

当サイト（WEBサイトサポート）は、この記事の手順の3番目を、サーバーの中から、自分のドメインに接続して確かめた。2026年10月21日の結果である。

• サーバーが送る鎖には、4枚の証明書があった。サイトの証明書の発行元はLet's Encrypt（中間はYE2）で、そのさらに上は、Let's EncryptのRoot YE、ISRG Root X2と、つながっていた。
• 鎖の中に、eMudhraやemSignの名前は、0件だった（鎖の全文を検索した結果）。

したがって、当サイトの証明書の発行元は、eMudhraの鎖につながるものではなかった。サーバー同士の通信については、05章の手順で当サイトのサーバー側も確かめ、2026年10月21日に必要な対処をした。記事の確認日以降に、結果が変わることもある。

確認の方法を数え直す大切さは、AI Ronのブログの「0件」に、探した数を書いていなかった ── 9種類で確かめた5日後、73種類で確かめ直したに書いた。今回の「0件」も、探した対象（鎖の中の4枚、2つの名前）を添えて書いている。

08 このテーマは、ここまで

2025年4月 — 中間証明書が作られた

テスト用サイトは、漏れた8枚の中間証明書が、2025年4月に作られたと書く。そのため、鍵が弱かった期間は、事故の公表より1年半ほど前から始まる、と読める。この読みは、テスト用サイトの記述に基づく。

2026年10月17日 — 報告とブラウザの遮断

最初の報告者が、各ルートプログラムのチームへ報告した日である。テスト用サイトによれば、FirefoxとChromeの遮断も、この日から始まった。

2026年10月19日 — 開示とAppleの遮断

問題が、下流の信頼リストの運営者へ開示された日である。Appleの端末の遮断も、この日から始まったと、テスト用サイトは書く。Cloudflareは、この日の約17:00 UTCに事故を知った。

2026年10月20日 — Cloudflareの更新とブログ

Cloudflareが、クライアントの更新・cloudflaredの更新・CDNとサーバー側の対策を、順に出した日である。ブログは、まだ多くの作業が残っているとも書く。Microsoftの遮断が始まったのも、この日だと、テスト用サイトは書く。

2026年10月21日 — この記事の確認日

この記事の内容は、2026年10月21日に、Cloudflareのブログ、テスト用サイト、Chromiumのページ、OpenSSLの文書、Cloudflareのドキュメントなどを開いて確かめた時点のものである。テスト用サイトの修正版の表には、NodeやBunなど、この日の時点で「pending（保留中）」のままの項目があった。表の内容は、変わりうる。出典のページが更新されたときは、この記事に日付つきで追記する。

この事故のあとの宿題

Cloudflareのブログは、今後の方向として、信頼リストを、固定された一覧ではなく、失効や、証明書の透明性の鍵などの情報で、素早く更新できる仕組みにする取り組み（upkiなど）を挙げる。サイト運営者にとっての宿題は、自分の通信の経路ごとに、信頼リストがどう更新されるかを、一度書き出しておくことである。05章の13番目は、その一覧を作る項目である。