eMudhra証明書8枚の鍵が危殆化、WARP更新を案内

eMudhraの中間証明書8枚に関連する秘密鍵が危殆化したと、Cloudflareが2026年10月20日（UTC）に公表しました。ブラウザやOSが広く信頼していた証明書の問題で、WARPやcloudflaredを使っている人、自前でTLSを構成している運用担当者に関係します。出典はCloudflareの公式ブログです。

eMudhraの証明書8枚で何が起きたのか
eMudhraの問題で更新したいWARPとcloudflared
eMudhraの証明書問題で運用側が見直したいこと
開発者がeMudhra対応で検証を無効にしてはいけない理由
eMudhra対応のこれまでの流れ
eMudhraの件でおすすめしたい対応

eMudhraの証明書8枚で何が起きたのか

結論から書くと、eMudhraの中間証明書8枚の鍵が弱く、攻撃者が任意のドメインの偽造証明書を作れる状態でした。Cloudflareは2026年10月19日の17:00 UTCごろにこの事態を把握したと説明しています。

つまり、攻撃者が本物のサーバーになりすまし、通信を傍受したり改ざんしたりできる可能性があるということです。この証明書は、ブラウザ、OS、Cloudflare内部で広く信頼されていました。Cloudflareは、インターネット全体に影響が及ぶ深刻なセキュリティインシデントだと説明しています。

ただし、Cloudflareのセキュリティレビューでは、同社のサービスで実際に悪用された形跡は確認されていません。また、問題はTLSの暗号アルゴリズムの弱点ではなく、証明書による相手の認証の部分です。

eMudhraの問題で更新したいWARPとcloudflared

まず確認したいのは、Cloudflare One Client（WARP）、1.1.1.1アプリ、Cloudflare Tunnel（cloudflared）の3つです。更新版は次のとおりです。

対象	更新後のバージョン
Cloudflare One Client	Android v2.5.6、iOS v1.12.16、Windows・macOS・Linux 2026.8.2115.0
1.1.1.1 アプリ	Android v6.38.10、iOS v6.31.7、Windows・macOS・Linux 2026.8.2115.0
Cloudflare Tunnel（cloudflared）	2026.10.2

iOSのCloudflare One Agentは、アプリ審査待ちで更新が公開されていません（10月20日 02:00 UTCの時点）。

cloudflaredをコンテナで動かしている場合は、修正済みのイメージに更新して再展開が必要です。更新版はcloudflaredのリリースページで公開されています。

また、Zero TrustのGatewayを使っていて、クライアントが最新であれば、自動的に保護されるとCloudflareは説明しています。

eMudhraの証明書問題で運用側が見直したいこと

Cloudflareは、CDNとサーバー側のZero Trustの対策を展開し終えています。ただし、さらなる対応は継続中で、やるべき作業はまだ多いと説明しています。一部の利用者は、自分で運用しているソフトウェアや信頼設定、特にオリジンサーバーで対応が必要です。

mTLS（クライアント証明書認証）を設定している場合は、クライアント証明書の検証に使う信頼ストアやアップロード済みのCAを見直す
暗号化モードがFull (strict)またはStrictの場合は、独自のオリジン証明書とサーバー構成を見直す
Cloudflare Containers（Sandboxesを含む）を使っている場合は、コンテナイメージとアプリの依存関係にある信頼ストアを確認し、デプロイ済みのイメージに合わせて更新する

Containersでは、HTTPS egress interception（外向きHTTPS通信の傍受設定）を有効にする方法もあります。外向きのHTTPSリクエストをCloudflare経由にして、接続先の証明書検証をCloudflare側の基盤へ移す仕組みです。有効にしているコンテナはすでに保護されています。

さらに、CloudflareはAutomatic SSL/TLSを更新し、信頼されなくなったeMudhraの証明書をまだ使っている場合に通知する予定です。そのまま使い続けると接続が壊れることがあるためです。

開発者がeMudhra対応で検証を無効にしてはいけない理由

開発者向けには、SDKの下を見る、という注意が出ています。APIクライアントは、証明書の検証をHTTPライブラリ、言語ランタイム、OS、独自の信頼設定のどれかに任せていることがあるためです。SDKを更新しただけでは、その下の検証方針が変わらない場合があります。

更新後に証明書エラーがダッシュボードなどに出ることもあります。ここで検証を無効にして済ませてはいけません。無効にすると、今回の更新が取り戻そうとしている認証の保護が外れてしまいます。

Mozillaのデニス・ジャクソン（Dennis Jackson）氏が、修正済みのよく使われるパッケージの一覧を集めています。間接的な依存関係に含まれることもあるため、依存ツリーまで見るのがおすすめです。同氏のテストサイトも、ブラウザでの確認方法と、ブラウザ以外の確認手順を案内しています。ただし、ブラウザのテストが通っても、バックグラウンドのサービスが安全とは限りません。curlのテストも、アプリが別の検証経路を使っていれば当てになりません。確認はアプリが実際に通るTLSの経路で行います。

eMudhra対応のこれまでの流れ

Cloudflareが公開した時系列は次のとおりです。時刻はUTCです。鍵が弱くなった原因は、Cloudflareのブログには書かれていません。

日時（UTC）	出来事
10月19日約17:00	Cloudflareが危殆化を把握し、評価を開始
10月20日 02:00	Cloudflare One ClientとWARPアプリの更新を公開（iOSのCloudflare One Agentはアプリ審査待ち）
10月20日 09:15	cloudflaredの更新を公開
10月20日 19:20	CDNとサーバー側のZero Trustの対策を展開完了

Cloudflareは、この影響が均等ではないと述べています。ブラウザの開発元は、更新するアプリが1つで済みます。そのうえ、多くのブラウザにはChromeのCRLSetsのような素早く失効させる仕組みがあり、設定の切り替えのように対処できました。Cloudflareは、この仕組みを他のシステムにも広げるため、upkiのような取り組みに期待しています。