Convika
無料で始める

eMudhra 中間証明書の問題：自分のサイトは対象？

Convika Team読了目安: 19 分

  • security
  • ssl
  • wordpress
  • rental-server
目次

情報は 2026 年 10 月 22 日 12 時（日本時間）時点です。動きの速い話なので、変わりやすい事実には確かめた日時を添えています。

インドの認証局 eMudhra の中間証明書 8 件で、秘密鍵が誰でもすぐ割り出せる弱い値だったことがわかり、ブラウザと OS の各社は 2026 年 10 月 17 日から 20 日にかけてこれを遮断しました。Let's Encrypt、Cloudflare、さくらのレンタルサーバの無料 SSL の証明書は eMudhra に連なっていないので、入れ替えは要りません。入れ替えが要るのはルート証明書「emSign ECC Root CA - G3」に連なる約 30,800 件（99.9% は米国の大学などが使う InCommon の発行）で、Chrome では 10 月 27 日から使えなくなります。

ITmedia や GIGAZINE、X のトレンドで「中間証明書」「秘密鍵」の見出しを見て、自分のお店や会社のサイトの鍵マークは大丈夫かと気になった方に向けて、この記事では 5 分で確かめられることを順に並べます。先に結論を書くと、ほとんどの小さなサイトで証明書の作業は要りません。残る作業は 2 つだけです。WordPress などのソフトが自分で持っている証明書の一覧の更新と、パソコンやスマホのブラウザと OS の更新です。

何が起きたか：eMudhra の中間証明書 8 件と、これまでの流れ

認証局は、サイトの証明書に「このサイトは本物です」という署名をする会社です。署名には秘密鍵を使い、その鍵を知っていれば誰でも本物と同じ署名を作れます。今回、eMudhra の中間証明書（ルート証明書の下で、実際にサイトの証明書に署名する証明書）8 件の秘密鍵が、本来は推測できないほど大きな数のはずが 256 未満の小さな整数でした（Mozilla のバグ管理システムのコメント 5）。6 件はサイトの証明書（TLS）用、2 件はプログラムの署名（コード署名）用です。

Google は、この鍵があれば「どのサイトにもなりすませる」偽の HTTPS 証明書を作れたと説明しています。報告したのは Wayne という研究者で、Chrome と Firefox は報告から数時間のうちに遮断しました。

日付（主に協定世界時）出来事出典
2025 年 4 月 30 日eMudhra の鍵の生成式で、問題の 8 件を含む 24 件の中間証明書が作られるMozilla Bugzilla 2083449
2026 年 10 月 17 日 18:05Chrome のルート証明書の担当（Chrome Root Program）に報告が届くGoogle
10 月 17 日 19:45Chrome が CRLSet という仕組みで TLS 用の 6 件の鍵を遮断。ブラウザの更新も再起動も要らなかったGoogle
10 月 17 日Firefox が OneCRL という仕組みで遮断Firefox 158.0.1 リリースノート
10 月 18 日 09:38eMudhra が 8 件を失効させる（理由は認証局の侵害）Mozilla Bugzilla 2083449
10 月 19 日Apple の機器で遮断Dennis Jackson（Mozilla）のまとめページ
10 月 19 日 22:00 ごろAndroid に Google Play 開発者サービス経由で遮断が届く。再起動するとすぐ反映されるGoogle
10 月 20 日Microsoft の環境で遮断。Firefox 158.0.1 が遮断の一覧を本体に入れて公開まとめページ、Firefox 158.0.1 リリースノート
10 月 20 日〜21 日Go 1.27.3 / 1.26.10、Node.js 22.23.4 / 24.22.1 / 26.12.1 などが修正版を公開Go の CVE 記録、Node.js のリリースノート
10 月 27 日（火）の朝、米国太平洋時間Chrome が「emSign ECC Root CA - G3」を信頼するルートの一覧から外す（日本時間では 27 日の夜から 28 日にあたる）Google

Chrome のルートの一覧（Chromium の root_store.textproto、バージョン 43）からは、2026 年 10 月 22 日 11 時 55 分に確かめた時点で emSign ECC Root CA - G3 がすでに消えており、eMudhra のルートで残っているのは「emSign Root CA - G1」だけでした。ただし、これは開発中のソースコードの状態で、配布中の Chrome の安定版で確かめたものではありません。

自分のサイトは対象か：証明書の発行元で決まる

対象かどうかは、サイトの証明書を誰が発行したか（発行元）だけで決まります。サーバーの会社や CMS の種類では決まりません。Chrome の担当者が証明書の公開記録（Certificate Transparency）を数えたところ、2026 年 10 月 21 日の時点で emSign ECC Root CA - G3 に連なる有効な証明書は約 30,800 件でした。そのうち 30,791 件（99.9%）は、米国の大学や研究機関が使う InCommon（運営は Internet2）の 2 つの中間証明書「InCommon Intermediate CA - OVG3C」（23,806 件）と「InCommon Intermediate CA - DVG3C」（6,985 件）の発行で、eMudhra 自身の中間証明書が発行したものは 18 件です（Mozilla Bugzilla 2083449 のコメント 30）。eMudhra も自社の発表（10 月 21 日更新）で、影響は「米国の 1 つの顧客の利用範囲」にとどまると書いています。

この数字からは、日本の小さなサイトはほぼ含まれないと読めます。ただし、日本のサイトで該当するものが 1 つもないかどうかは、この記事では確かめられていません。

サイトの証明書の発行元今回の対象かすること
Let's Encrypt対象外。Let's Encrypt の証明書は ISRG（Let's Encrypt の運営団体）のルートに連なり、eMudhra を通らないなし
Google Trust Services対象外。Google のルートに連なるなし
Cloudflare の自動の SSL（Universal SSL など）対象外。Cloudflare の文書では、発行元は Let's Encrypt、Google Trust Services、SSL.com（文書の更新日は 2026 年 4 月 16 日、10 月 22 日 11 時 55 分に確認）なし。ただし、Cloudflare の外にある自分のオリジンサーバーの設定は別（下の「サーバーを自分で管理している場合」）
さくらのレンタルサーバの無料 SSL対象外。さくらインターネットの公式ページは、無料 SSL を Let's Encrypt と案内している（10 月 22 日 11 時 57 分に確認）なし
エックスサーバーなど、ほかのレンタルサーバーの無料 SSLこの記事では未確認。エックスサーバーの無料 SSL のページは 10 月 22 日 11 時 55 分に開けなかった（503）次の節の方法で、自分のサイトの発行元を見る
会社から買った有料の証明書発行元しだい発行元を見る。下の 2 行に当たらなければ対象外
「InCommon Intermediate CA - OVG3C」「InCommon Intermediate CA - DVG3C」対象すぐに、別の認証局の証明書に入れ替える。Chrome では 10 月 27 日から使えなくなり、更新済みのソフトからはすでにつながらない場合がある（表の下の説明）
名前に「emSign」や「EM」と「G3」を含む eMudhra の中間証明書対象同じく、すぐに入れ替える

Google は、このルートに連なる証明書を使うサイトの運営者に、Chrome のルートの一覧にある別の認証局から新しい証明書を「すぐに」取って入れるよう求めています。期限は Chrome の 10 月 27 日だけではありません。Mozilla は証明書の一覧（NSS 3.131.1）からこのルートを外す更新を進めており（eMudhra の発表が引く Mozilla の説明）、Node.js 24.22.1 の組み込みの一覧からはすでに外れています（Node.js のソースコードで 10 月 22 日 12 時 23 分に確認）。こうした更新済みのソフトからは、すでにつながらない場合があります。eMudhra は、対象の利用者に直接連絡し、移行を手伝うとしています。

自分のサイトの証明書の発行元を 1 分で見る方法

いちばん手早いのはブラウザです。Chrome、Edge、Safari では、アドレスバーの左にあるアイコン（鍵などの印）から接続の情報を開き、証明書を表示すると「発行元」（英語の画面では Issued By）が出ます。画面の言葉と押す場所はブラウザとバージョンで変わり、この記事では画面の手順を 1 つずつは確かめていません。発行元の欄にある「O」（組織名）と「CN」（名前）を、上の表と見比べてください。

ターミナルが使える方は、次のコマンドで同じことがわかります。example.com を自分のサイトのドメインに置き換えます。

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer

2026 年 10 月 22 日 11 時 58 分に、macOS 26.5.2 と OpenSSL 3.6.3 で convika.com に向けて実行すると、issuer=C=US, O=Google Trust Services, CN=WE1 と出ました。これは「Google Trust Services の WE1 という中間証明書が発行した」という意味で、上の表では対象外の行に当たります。

サーバーが送ってくる証明書の連なり全体に eMudhra や InCommon の名前があるかは、次のコマンドで探せます。接続に失敗したときも何も表示されないので、先に 1 つ目のコマンドで issuer= の行が出ることを確かめてから使ってください。そのうえで何も表示されなければ、そうした名前は含まれていません。何か表示されたら、その行の名前に「G3」があるかを見て、上の表と照らします。

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -i -E "emsign|emudhra|incommon"

WordPress など、自分で証明書の一覧を持つソフトを使っている場合

サイトの証明書が対象外でも、もう 1 つ見ておく場所があります。サーバーの上のソフトが「どの認証局を信じるか」の一覧を自分で持っている場合です。ブラウザは遮断の仕組みを持っていますが、多くのソフトはこの一覧を更新しない限り、漏れた鍵で作られた偽の証明書を見抜けません。

WordPress は、更新の確認やプラグインの API、外部サービスとの通信など、サイトのサーバーから外へつなぐ HTTPS の通信で、本体に入った wp-includes/certificates/ca-bundle.crt を標準で使います（7.1 系のソースコード class-wp-http.php の 229 行目）。この一覧は、開発中の版（trunk）では 2026 年 10 月 21 日 03:15（協定世界時）の変更で新しくなり、emSign ECC Root CA - G3 が外れました（チケット #66355）。一方、10 月 22 日 11 時 55 分の時点で最新版は WordPress 7.1.3 で、7.1 系の一覧（Mozilla の 2026 年 7 月 16 日時点のデータ）にはこのルートがまだ入っています。つまり、修正の入った WordPress はまだ公開されていません。

影響するのは、サイトのサーバーが外へつなぐ通信だけで、訪問者がサイトを開くときの鍵マークには関係しません。悪用するには、サイトのサーバーと通信先のあいだの通信経路に割り込む必要があり、1 つの WordPress サイトにとっての危険は高くありません。管理画面の操作で今日できることはなく、この一覧を新しくした版が出たら WordPress を更新すれば足ります。証明書のエラーが出ても、証明書の確認を切る設定（プラグインやコードで検証をオフにすること）はしないでください。Cloudflare は、確認を切ると、更新で取り戻すはずの守りそのものがなくなると注意しています。

PHP で Composer を使っている場合は、composer/ca-bundle の 1.4.16 または 1.6.0 で修正されています。レンタルサーバーで PHP 自体が使う証明書の一覧は、サーバーの会社が更新する部分です。

サーバーを自分で管理している場合（VPS・クラウド・Docker）

自分で管理するサーバーやコンテナでは、OS の証明書の一覧と、言語やツールが持つ一覧の両方を更新し、そのあとでサービスを再起動します。更新したファイルは、動いているプロセスが読み直すまで使われません。

  • OS の証明書の一覧（ca-certificates）: Ubuntu、Debian、Alpine、Fedora、Arch、FreeBSD などの修正版は、Dennis Jackson（Mozilla）のまとめページに一覧があります（10 月 22 日 11 時 55 分に確認）。Debian のセキュリティ勧告（DSA/DLA）は、この記事では見つけられていません。
  • 言語とツール: Go 1.27.3 / 1.26.10、Node.js 22.23.4 / 24.22.1 / 26.12.1、Python の certifi 2026.10.19 と pip 26.2.2、Java の各版、Deno 2.9.8 などが修正済みで、Bun と Erlang の certifi は 10 月 22 日 11 時 55 分の時点で対応中です（まとめページの表記は pending）。Node.js のこの 3 つの版は、Brotli 形式の展開処理の脆弱性（CVE-2026-111497）を含む、合わせて 10 件の脆弱性を直したセキュリティリリースです。更新の手順は Node.js October 2026 security release: what to update（英語）にあります。ブラウザ、ランタイム、ライブラリごとの対応状況と確かめるコマンドは、Chrome's eMudhra root removal on October 27: what to do（英語）にあります。
  • コンテナ: イメージを作り直して入れ替えます。Cloudflare は、間接的な依存も含めて更新し、再読み込み、再起動、再デプロイが要るかを確かめるよう勧めています。
  • Cloudflare を前に置いている場合: Cloudflare は、利用者が対応するところとして、オリジンサーバーの証明書と設定（Full (strict) の場合）、相互 TLS で信じる認証局の一覧、cloudflared（2026.10.2 に更新）を挙げています。

Mac に最初から入っている curl、git、python3 などは /etc/ssl/cert.pem を使い、このファイルは更新されていません（まとめページ）。この記事を書いた Mac（macOS 26.5.2）で 10 月 22 日 11 時 58 分にまとめページの確認用アドレス https://dv-g3b-emudhra.we-have-a-problem.com/ を /usr/bin/curl で開くと、エラーにならずに応答が返りました。まとめページの説明では、エラーになるのが安全な結果です。まとめページには手で直す方法も載っていますが、Linux の手順は「普通の利用者には勧めない」と書かれています。

お客様に知らせたいとき：お知らせのページを 1 枚

お客様から「お店のサイトは大丈夫？」と聞かれたら、確かめた結果を 1 枚のページにまとめて、リンクや QR コードで渡せます。

Convika では、お知らせの内容を AI に伝えると 1 分ほどで非公開のプレビューができ（ChatGPT などで作った HTML ファイルを置くこともできます）、公開するとリンクと QR コードが出ます。登録から公開まで無料です。

無料でお知らせのページをつくる

パソコンやスマホを使うだけの人がすること

ブラウザと OS を最新にしておけば足ります。Chrome と Firefox は 10 月 17 日に、利用者が何もしなくても遮断を受け取っています（Google、Firefox）。Android は再起動すると、Google Play 開発者サービス経由の遮断がすぐに入ります（Google）。Firefox で、会社の設定などで遮断の一覧を受け取れない環境は、158.0.1 への更新で一覧が入ります。

「証明書の問題」で出てくる別の話との見分け方

「証明書 問題」で検索すると、同じ 10 月の別の話が並びます。どれも eMudhra とは関係がありません。

話何のことか自分のサイトとの関係出典
Windows のセキュアブートの証明書パソコンの起動を守る「Microsoft Windows Production PCA 2011」の期限が 2026 年 10 月 19 日。新しい 2023 年版を受け取っていない端末も起動はするが、起動まわりの新しい保護を受け取れなくなるなし（パソコンの話）Microsoft サポート（10 月 22 日 12 時に確認）
Let's Encrypt の有効期間 64 日2027 年 2 月 10 日から、Let's Encrypt の証明書の有効期間が標準で 64 日になる。脆弱性ではないACME Renewal Info（ARI）に対応した自動更新なら作業は要らない。更新の時期を日数で決め打ちしている場合（cron などに書いた 60・80・83 日など）は、有効期間の約 3 分の 2 で更新するよう見直すLet's Encrypt（10 月 22 日 12 時に確認）
Node.js の TLS の修正（10 月 21 日）Node.js のプログラムが接続先の証明書を確かめるときの、IP アドレスの扱いの不具合（CVE-2026-106069 など）の修正Node.js で外につなぐプログラムを動かしている場合だけNode.js 24.22.1 のリリースノート（10 月 22 日 11 時 55 分に確認）

悪用はあったか

10 月 22 日 12 時の時点で、悪用を確認したという発表は見つかっていません。わかっていることと、わかっていないことは次のとおりです。

  • Google: 遮断より前に、6 件の TLS 用の中間証明書に連なる証明書は公開記録（Certificate Transparency）に 1 件も載っていなかったため、公開記録を確かめる Chrome などに対しては偽の証明書を使えなかった、としています。
  • まとめページ（Mozilla の Dennis Jackson）: Firefox、Chrome、Edge、Safari は攻撃を受けえなかったと書く一方、ブラウザ以外の多くのソフトは公開記録を確かめないため、それらが狙われたかどうかは「わからない」としています。
  • Cloudflare: 自社のサービスで悪用は見つかっていない、としています。
  • eMudhra: 8 件のうち本番で使っていたのは 1 件だけで、どれもサイトの証明書を 1 件も発行していない、と自社の発表（10 月 20 日、21 日更新）で説明しています。

この件そのものに CVE の番号はありません。番号がついたのは Go の修正（CVE-2026-111943、2026 年 10 月 21 日公開）で、記録に CVSS の点数はありません（10 月 22 日 11 時 55 分に確認）。日本の JPCERT/CC と IPA は、10 月 22 日 11 時 56 分の時点で、この件の注意喚起を出していません。

Convika で公開したページの証明書

この記事を書いている Convika は、ページを公開するサービスです。Convika で公開したページの証明書は、持ち主が買ったり入れ替えたりするものではなく、自動で発行されます。2026 年 10 月 22 日 11 時 54 分に確かめたところ、○○.convika.page のページの証明書は Let's Encrypt（YE2）の発行で、ISRG のルートに連なっており、連なりのどこにも eMudhra の証明書はありませんでした。独自ドメインの証明書は Cloudflare を通して自動で発行され、どの認証局になるかは Cloudflare が決めます。お店の案内のように 1 枚のページで足りるなら、WordPress や PHP の更新を自分で持たず、証明書も自動で更新される置き方もあります。独自ドメインのつなぎ方は AI で作ったページを無料で独自ドメインに公開する方法 にまとめています。

よくある質問

eMudhra の脆弱性は自分のサイトに関係ありますか？

サイトの証明書の発行元が Let's Encrypt、Google Trust Services、SSL.com、Cloudflare の自動の SSL なら、サイトの証明書の入れ替えは要りません。WordPress など、サーバーから外へつなぐソフトが持つ証明書の一覧は別の話で、修正版が出たら更新します。証明書の入れ替えが要るのは、発行元が「InCommon Intermediate CA - OVG3C」「InCommon Intermediate CA - DVG3C」か、名前に「emSign」や「EM」と「G3」を含む eMudhra の中間証明書の場合で、約 30,800 件のうち 99.9% は米国の InCommon の発行です（Chrome の数え、2026 年 10 月 21 日時点）。該当するなら、すぐに別の認証局の証明書へ入れ替えます。Chrome では 10 月 27 日から使えなくなり、更新済みのソフトからはすでにつながらない場合があります。

自分のサイトが eMudhra の中間 CA を使っているかどうか、どう確かめますか？

ブラウザでアドレスバーの左のアイコンから証明書を開き、「発行元」を見ます。ターミナルなら openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer で発行元が表示されます。発行元に emSign、eMudhra、InCommon の名前がなければ、今回の対象ではありません。

Let's Encrypt の証明書は影響を受けますか？

受けません。Let's Encrypt の証明書は ISRG のルートに連なり、eMudhra の中間証明書もルートも通りません。Chrome の数えでは、問題のルートに連なる証明書は InCommon と eMudhra 自身の中間証明書が発行したものです。Let's Encrypt の有効期間が 2027 年 2 月 10 日から 64 日になる話は、これとは別の予定です。

レンタルサーバーの無料 SSL は入れ替えが必要ですか？

さくらのレンタルサーバの無料 SSL は Let's Encrypt なので、入れ替えは要りません（さくらインターネットの公式ページ、2026 年 10 月 22 日 11 時 57 分に確認）。エックスサーバーなどほかの会社は、この記事では公式ページで確かめられていません。自分のサイトの発行元を見れば、会社を問わず判断できます。

証明書エラーが急に出るようになりました。今回の件と関係がありますか？

多くの場合は関係ありません。関係するのは、eMudhra の G3 のルートに連なる証明書を使うサイトを 10 月 27 日以降に Chrome で開いた場合と、サーバーで更新した証明書の一覧が、eMudhra に連なる接続先を拒むようになった場合です。どちらの場合も、証明書の確認を切って直さないでください。

WordPress は更新が必要ですか？

訪問者から見たサイトの証明書には関係しません。WordPress が外へつなぐ通信で使う証明書の一覧には問題のルートが残っていて、修正は開発中の版に入りましたが、2026 年 10 月 22 日 11 時 55 分の時点で最新の 7.1.3 にはまだ入っていません。修正の入った版が出たら更新してください。今日、管理画面でできることはありません。

中間証明書、ルート証明書、認証局の違いは？

認証局は証明書を発行する会社です。ルート証明書は、ブラウザや OS が最初から「信じる」と決めている認証局の大元の証明書で、中間証明書はその下でサイトの証明書に実際に署名する証明書です。今回は eMudhra の中間証明書 8 件の秘密鍵が弱く、その上のルート「emSign ECC Root CA - G3」も Chrome が外すことになりました。

Chrome のルート削除はいつですか？

Google は、emSign ECC Root CA - G3 を外す変更が、米国太平洋時間の 2026 年 10 月 27 日（火）の朝に、Chrome のルートの一覧を使うすべての端末に届く見込みだとしています。日本時間では 27 日の夜から 28 日にあたります。Chrome Canary や Beta にはそれより早く入ります。

出典

報道では ITmedia NEWS（10 月 21 日）や GIGAZINE（10 月 22 日）が取り上げています。この記事の事実は、上の一次の出典で確かめたものです。

続報

  • 2026 年 10 月 22 日: 12 時時点の情報で公開。

関連記事

記事を共有する