Cloudflareの追跡で、eMudhraの弱い鍵の更新は端末ごとにまだらだった。Android WebViewは30〜40%が受け入れ ── 端末と通信の相手を種類ごとに数えて確かめる13項目（2026年11月時点）

目次

1. 01 何が書いてあるか — Cloudflareの追跡は、サーバー側が直っても、見る側の端末と通信の相手の更新がまだらだったと数字で示した
   1. 弱い鍵と、10月19日からの動き
   2. Cloudflare自身の側で起きたこと
   3. 見る側の数 — 約5,000万回の確認
   4. 10月29日の分類の変更
2. 02 なぜ・背景 — 数字は、測り方が変わると動く
   1. サーバー側が直しても、見る側は別
   2. 測り方が変わると、数字も動く
   3. 傍受の証拠が無いことは、起きなかったことの証明ではない
   4. 前の記事（eMudhraの中間証明書の件）と、今回の追跡の関係
   5. 運営者が気にする3つの場面
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. 信頼リスト（トラストストア）
   2. 中間証明書と、失効
   3. WebView
   4. 確認の通信（プローブ）
4. 04 型別 — 対象、確かめられないこと、確かめる手順
   1. 🅰 適用範囲 — この記事が役に立つ人
   2. 🅱 この情報が測っていないこと
   3. 🅲 手順1 — 端末と通信の相手を、種類ごとに書き出す
   4. 🅲 手順2 — アクセスの記録から、端末の種類を数える
   5. 🅲 手順3 — 自社のサーバーが外へつなぐ相手を数える
   6. 🅲 手順4 — 公式の試験用のサイトで、手元の端末を確かめる
   7. 🅲 手順5 — 更新できない端末の扱いを、文章にする
5. 05 明日、担当サイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 端末を更新できないときの考え方
   1. 運営者にできることと、できないこと
   2. 信頼リストを素早く更新する方向
   3. 数字が良くなったように見えたとき
7. 07 当サイトで確かめたこと — サーバーから外へつなぐ側は、すでに塞いだ
8. 08 このテーマは、ここまで — eMudhraの件を追った記事の流れ
   1. これまでの記事
   2. 今回の記事の位置
9. 09 この記事のまとめ

01 何が書いてあるか — Cloudflareの追跡は、サーバー側が直っても、見る側の端末と通信の相手の更新がまだらだったと数字で示した

認証局eMudhraが弱い鍵を使っていた件は、10月19日に分かり、Cloudflareは同じ日に自社の仕組みの更新を始めた。10月30日のCloudflareの記事は、その後の1週間ほどの追跡である。この記事が取り上げるのは、悪用の件数よりも、「サーバー側の対策が済んでも、それを見る側の端末や、つなぐ相手が追いついていないことがある」という点だ。担当サイトを運用する人は、自分のサーバーだけでなく、訪問者の端末と、自社が外へつなぐ相手を、種類ごとに数える必要がある。

弱い鍵と、10月19日からの動き

原文によると、eMudhraは認証局の鍵を作るときに、本来は115桁ほどの大きな数になるはずの値に、とても小さな数を選んでいた。弱い値は8つあり、4、56、66、115、155、156、230、237である。原文は、この鍵が公開されている証明書の情報だけからほぼ一瞬で割り出せると書き、過去の認証局の事件との違いにしている。eMudhraは、公の認証局の事業から退くと述べ、原因を鍵を作る手順の誤りとしているが、その手順は公開していない。

この件の背景と、担当サイトの信頼の経路の確かめ方は、すでに当サイトの記事「認証局eMudhraの中間証明書8枚の秘密鍵が漏れた。テスト用サイトによればブラウザは遮断済みで、残るのはブラウザの外の通信 ── 自社と担当サイトの信頼の経路を確かめる13項目（2026年10月時点）」にまとめてある。今回の記事は、その続きとして、10月30日のCloudflareの追跡が加えた数字を読む。

Cloudflare自身の側で起きたこと

Cloudflareは、外へつなぐ通信の大半を扱う自社の部品に、10月21日までに記録を足した。そこから約1週間で、弱いeMudhraの鍵を使った接続の試みは約22,000回あった。その約3分の2は、試験用のサイトへの接続だった。残りの大半は、配信元が自分用の証明書を用意したように見える接続で、その証明書は弱い中間の鍵を使っていた。

証明書を確かめる設定の接続は、更新済みのため、すべて断られたと原文は書く。さらに約160回の接続では、証明書に書かれた名前が、つなごうとしたドメインとは別の組織のドメインだった。その中には家庭向けの機器のドメインもあった。原文は、これらを傍受の試みというより、サーバーが初めから持っていた標準の証明書に見えると読んでいる。ただし、弱い鍵を使った偽の証明書のうち1つは、証明書に書かれた日付が、Mozillaの不具合報告の公開から1時間以内になっていた例も挙げる。

見る側の数 — 約5,000万回の確認

Cloudflareは、人かどうかを確かめる画面に、2本の小さな通信を足した。1本は弱い鍵の鎖で、もう1本は通常の鎖である。弱い鎖を受け入れるかどうかを見れば、その端末が更新済みかが分かる。ただし、動くのはJavaScriptを実行する相手、つまりブラウザなどに限られる。Cloudflareの記事は、約5,000万回の確認を足し合わせたと書き、その偏りも認める。自動の相手が多く混ざり、全部が確認されたわけではない。

10月29日の分類の変更

Cloudflareの記事には、読み間違えやすい箇所がある。10月29日の18時ごろ（UTC）に、Cloudflareが新しい検知を入れたところ、macOS上のChrome 150から154を名乗る自動の通信が大量に見つかった。この結果、グラフ上は「macOSで更新が進んだ」ように見えたが、実際は通信の分類が変わっただけだった、と原文は書く。同じ名乗りの通信は、自動の印がある側の図では、受け入れの割合が高かった。

02 なぜ・背景 — 数字は、測り方が変わると動く

サーバー側が直しても、見る側は別

認証局の鍵の件は、「サーバーの証明書を入れ替えれば終わる」種類の話ではない。問題は、どの証明書を信頼するかを決めるのが、見る側の端末だという点にある。サーバーを運用する人が証明書を入れ替えても、訪問者のスマートフォンやアプリが古い信頼のリストを持っていれば、危険な鎖を受け入れる状態が残る。Cloudflareの記事は、最新のブラウザは多くが更新済みだが、自動の通信や古いブラウザは更新されていないと書く。

測り方が変わると、数字も動く

追跡の途中で、測り方は何度か変わっている。原文によると、10月23日に比較用の通信の設定が変わり、10月27日にも鎖の設定と確認の割合が変わり、10月29日には自動の通信の分類が変わった。筆者の読みでは、経過のグラフを「更新が進んだ」「止まった」と読む前に、測り方の変更の日付を並べるのが安全である。数字が動いた日と、設定が変わった日が重なっていたら、その数字は更新の進み具合の証拠にならない。

傍受の証拠が無いことは、起きなかったことの証明ではない

Cloudflareの記事は、弱い鍵がCloudflareの接続の傍受に使われた証拠は、今のところ見つかっていないと書く。同時に、慎重に狙った傍受は否定できないとも書き、間接的な侵害の兆しも見ていないと述べる。「見つかっていない」と「無かった」は別の言葉である。担当サイトの報告に書くときは、原文と同じ強さで書く。

前の記事（eMudhraの中間証明書の件）と、今回の追跡の関係

当サイトの前の記事（認証局eMudhraの中間証明書が漏れた件）は、試験用のサイトの結果をもとに、ブラウザは遮断済みで、残るのはブラウザの外の通信という整理で書いた。今回のCloudflareの追跡は、その「ブラウザの外」の中身を、数字で細かく見たものと読める。ただし、追跡の数字は、ブラウザの更新が十分に進んだと書くのではなく、更新済みの割合が、端末と通信の相手の種類によってまだらだと書いている。「遮断済み」と読めるのは、更新が届いた種類に限られる。

運営者が気にする3つの場面

日本の中小の運営者にとって、この件が現実の作業になる場面は、おおよそ3つに分けられる。1つ目は、自社のアプリの中で、自社のWEBページを表示している場合である。アプリの中のページ表示は、端末のブラウザとは別の部品が担当する可能性があり、更新の速さも別になる。2つ目は、自社のサーバーが、決済やメールなどの外部のサービスへつなぐ場合である。ここは運営者が直せる側にある。3つ目は、古いスマートフォンの利用者が一定数いる場合で、運営者が直せない側にある。

3つの場面は、直せるかどうかが違う。直せる側は台帳で期限を決めて埋め、直せない側は割合を知って、対象にする端末の古さを決める。この切り分けを先にしておくと、同じ「更新が進んでいない」という言葉でも、次にやることが変わる。

03 用語 — 出てくる言葉を、先にそろえる

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

中間証明書と、失効

中間証明書は、認証局が、サーバーの証明書に署名するために使う、1つ下の層の証明書である。弱い鍵の中間証明書があれば、その鍵を割り出した人は、好きなドメインの偽の証明書を作れる。失効は、認証局の側で「この証明書は信じないでほしい」と知らせる手続きだが、その知らせを端末が受け取るには、端末側が更新を取り込む仕組みを持つ必要がある。

WebView

WebViewは、アプリの中にWEBページを表示するための部品である。Android WebViewは、Android端末のアプリの中のページ表示に使われる。原文は、WebViewの更新が遅れていると書く。ブラウザのアプリとは別の更新の経路かどうかは、書かれていない。

確認の通信（プローブ）

原文の確認の通信は、端末が弱い鎖を受け入れるかを調べる小さな通信である。1つは弱い鎖、もう1つは比較用の通常の鎖で、2つの結果を比べる。人かどうかを確かめる画面のように、JavaScriptが動く環境でしか実行できない。

04 型別 — 対象、確かめられないこと、確かめる手順

🅰 適用範囲 — この記事が役に立つ人

担当サイトを持つ人は、2つの立場にいる。見られる側（訪問者の端末が、サイトの証明書を確かめる）と、見る側（自社のサーバーや業務のパソコンが、外のサービスの証明書を確かめる）である。この記事の手順は、どちらにも使える。特に、自社のアプリの中にWEBページを表示している人、外部のサービスへ自社のサーバーからつないでいる人、古い端末の利用者が一定数いるサイトの運営者に当てはまる。

🅱 この情報が測っていないこと

Cloudflareの追跡は、自社の通信と、自社の確認画面を通った端末だけを見ている。次のことは測っていない。担当サイトの訪問者の端末の割合。記事に出る「大きな回線」が、日本のどの回線に当たるか。業務用のパソコンや、アプリの中の部品の更新の状態。原文は、偏りの多い数字だと自分で書いている。

Cloudflareの数字は、「更新が進むまでの時間が、端末の種類で違う」ことを示した資料として読める。「何日で何割が更新される」という一般の法則を示した資料としては読めない。

🅲 手順1 — 端末と通信の相手を、種類ごとに書き出す

メモ帳に、端末と通信の相手を、種類ごとに1行ずつ書く。種類は6つに絞ってよい。訪問者のブラウザ、アプリの中のページ表示（WebView）、自社のアプリ、自社のサーバーが外へつなぐ相手（決済・通知・地図など）、監視や計測のサービス、業務用のパソコンである。

🅲 手順2 — アクセスの記録から、端末の種類を数える

サイトのアクセスの記録から、名乗りの種類を分けて数える。ブラウザの種類、OSの種類、アプリの中のページ表示と思われるものを3つの列にし、直近の7日分の割合を書く。名乗りは偽装できるため、割合の数字は目安にしかならない。名乗りの確かめ方は、当サイトの記事「Googlebotの名乗りは誰でも書ける。通す・止めるを名乗りだけで決めず、接続元で確かめる ── 自分のサイトの判定を点検する13項目（2026年10月時点）」にある。サイトの状態をまとめて見る入口には、🔧 WEBサイト総合分析・レポートツール — 公開ページの状態をまとめて確認するが使える。

🅲 手順3 — 自社のサーバーが外へつなぐ相手を数える

決済、メール送信、検索の通知、外部の情報の取得など、自社のサーバーから外へつなぐ相手を、名前とドメインで書き出す。数は10個前後になる場合が多い。それぞれの相手について、通信に使う証明書の発行元を1つ確かめる。当サイトでは、ブログの記事「認証局の中間証明書8枚の秘密鍵が漏れた週、当サイトのサーバーの中からつなぐ通信は、漏れた証明書を通していた ── AIの知らせを自分で測り直して、塞いだ記録」で、この確認を行った。

🅲 手順4 — 公式の試験用のサイトで、手元の端末を確かめる

原文は、更新の手順と確認用の試験用のサイトを挙げている（出典欄に記載）。手元の端末で1回開き、結果を台帳に書く。アプリの中のページ表示と、ブラウザのアプリは、別の部品である可能性があるため、同じ端末で2回開いて結果を分けて書く。結果の見方は、試験用のサイトの説明に従う。ここに書かれた見方を、この記事では確かめていない。

🅲 手順5 — 更新できない端末の扱いを、文章にする

訪問者の端末は、運営者が更新できない。そこで、どの古さの端末までを動作の対象にするかを、1行の文章にする。例は、「提供元のサポートが終わった版のOSは、動作の対象にしない」である。対象外の端末が一定の割合で来ていることが分かったら、サイトに案内の文を出すか、利用者にどう伝えるかを、担当者と決める。

アプリの中のページ表示を使っている場合は、アプリの提供元（自社か、外部の開発会社か）を台帳に書く。外部の開発会社が作ったアプリなら、担当の列に、その会社の担当者の名前を書く。名前が書けない行は、確認の優先度が高い行である。

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

以下は、端末と通信の相手を種類ごとに数え、信頼の経路が追いついているかを確かめる13項目である。1〜3番目は数字の読み取り、4〜7番目は台帳づくりと端末の数え方、8〜10番目は外へつなぐ相手、11〜13番目は手元の確認と更新の方針である。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。

• Cloudflareのブログ記事を開き、Android WebViewの数字（30〜40%）と、大きな回線の数字（半分を超える）をメモ帳に書き写す
• 原文の図の下にある、測り方の変更（10月23日、27日、29日）の日付を3つ書き写して、数字が動いた日と重なる箇所に印をつける
• メモ帳に「この数字は、Cloudflareの確認画面を通った端末の割合で、自社の訪問者の割合ではない」と1行書く
• 端末と通信の相手の台帳を表計算ソフトで1枚作り、種類・例・更新の仕組み・確かめ方・担当の5列を並べる
• 台帳の種類の列に、訪問者のブラウザ、アプリの中のページ表示、自社のアプリ、外へつなぐ相手、監視や計測、業務用のパソコンの6行を書く
• 直近7日のアクセスの記録から、名乗りの種類ごとの割合を3つの列（ブラウザ・OS・アプリの中のページ表示と思われるもの）で書く
• アクセスの記録の数え方を1行で書き、名乗りが偽装できる点を台帳の注記に書く
• 自社のサーバーが外へつなぐ相手を、決済・メール・通知・取得の4つの用途から探し、見つかった相手のドメインを書き出す
• 見つかった相手のうち3つを選び、通信に使う証明書の発行元を、ブラウザの証明書の表示で確かめて書く
• 外へつなぐ相手の一覧に、確かめた日と、次に確かめる日（1か月後）を書く
• 手元の端末（スマートフォンとパソコンの2台）で、原文が挙げる試験用のサイトを開き、結果を台帳に書く
• アプリの中にページを表示している場合は、アプリの中と、ブラウザのアプリで、同じ試験用のサイトを開いて結果を分けて書く
• 動作の対象にする端末の古さの下限を、1行の文章で書き、担当者に見せて承認の日を書く

チェックが終わったら、台帳に「最後に確認した日」を書き、次に確認する日を月に1回で決める。

06 代替・他の選択肢 — 端末を更新できないときの考え方

運営者にできることと、できないこと

訪問者の端末を、運営者が更新させることはできない。運営者にできるのは、自社のサーバー、自社のアプリ、業務のパソコンの3つである。この3つを先に台帳で埋め、訪問者の端末は「割合を知る」「古い端末を対象外にする」の2つで扱うのが現実的である。

信頼リストを素早く更新する方向

原文は、信頼リストが固定の一覧のままでは、失効の知らせに素早く対応できないと書き、方向の例として、あるプロジェクトを挙げる。筆者の読みでは、これは運営者がすぐに使える手段ではなく、端末の提供元とブラウザの提供元に向けた提案である。担当サイトの運営者は、この方向の動きが出たら、台帳の「更新の仕組み」の列に追記する、という使い方になる。

数字が良くなったように見えたとき

将来、「更新が進んだ」という数字が出ても、10月29日のmacOSの例のように、分類が変わっただけの場合がある。筆者の案として、数字が良くなったときこそ、測り方の変更の日付を先に確かめる。確かめる前に、担当サイトの報告に「進んだ」と書かない。

07 当サイトで確かめたこと — サーバーから外へつなぐ側は、すでに塞いだ

当サイトは、2026年10月21日に、サーバーから外へつなぐ通信の信頼リストから、問題の発行元の根の証明書を外した。外した後、公式の試験用のサイトへのサーバーからの接続は失敗するようになった。経緯と確かめた内容は、ブログの記事160に書いた（リンクは関連記事の欄）。設定の値やファイルの場所は、この記事には書かない。

一方、当サイトの訪問者の端末が、どの鎖を受け入れているかは、当サイトの記録からは分からない。端末が証明書を確かめる処理は、端末の中で終わり、サーバーのアクセスの記録には残らないからである。見えるのは名乗りの種類までで、名乗りは偽装できる。このため、当サイトは、訪問者側の割合を数字で書かない。

08 このテーマは、ここまで — eMudhraの件を追った記事の流れ

これまでの記事

• 認証局eMudhraの中間証明書8枚の秘密鍵が漏れた。テスト用サイトによればブラウザは遮断済みで、残るのはブラウザの外の通信 ── 自社と担当サイトの信頼の経路を確かめる13項目（2026年10月時点） — 件の発覚と、信頼の経路の確かめ方
• 認証局の中間証明書8枚の秘密鍵が漏れた週、当サイトのサーバーの中からつなぐ通信は、漏れた証明書を通していた ── AIの知らせを自分で測り直して、塞いだ記録 — 当サイトで外へつなぐ通信を確かめた記録
• 圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった ── 当サイトが外から圧縮を受け取る場所を数え、その日のうちに塞いだ記録と、同じ日にサーバーが止まったあとの確かめ方 — 受け取る側の部品を数える
• Googlebotの名乗りは誰でも書ける。通す・止めるを名乗りだけで決めず、接続元で確かめる ── 自分のサイトの判定を点検する13項目（2026年10月時点） — 名乗りの確かめ方

今回の記事の位置

前の記事（認証局eMudhraの中間証明書が漏れた件）は、ブラウザの外の通信に注意を向けた。今回は、Cloudflareの数字を借りて、見る側の端末と通信の相手が、種類によってまだらに更新されることを示し、台帳の種類を6つに分けた。サーバー側の対策は「済んだ日」を書けるが、見る側の対策は「どの種類が何割追いついたか」でしか書けない。この違いが、今回の記事の中心である。

次にこの件の続報が出たときは、台帳の6つの種類のどの行に関係する話かを先に決めてから読む。関係する行が無い話なら、台帳は変えずに、確認した日だけを書き足せばよい。続報の数字を読むときは、02章で並べた「測り方が変わった日」と同じ観点で、日付を先に確かめる。