eMudhra中間証明書の秘密鍵問題まとめ：ブラウザは守られた、残るのはGo・Tailscale・OSの証明書ストア・コンテナ

2026年10月17日（土）、インドの認証局eMudhra（イームドラ）が運用していた「中間証明書」8枚について、その秘密鍵が公開されている証明書から誰でも計算できてしまう、という報告が世界の主要なブラウザの担当チームに届きました。

秘密鍵の中身は、本来なら100けたを超える乱数であるはずのところ、256より小さな数でした。そのうちのひとつは、ただの「4」だったと報告されています。

この鍵を持っていれば、理屈の上では、どんなWebサイトの「本物の証明書」でも作れてしまいます。Google ChromeとFirefoxは報告から数時間のうちにこの証明書を遮断し、Apple、Microsoftもそれに続きました。ブラウザを使っている普通の利用者は、更新ボタンを押さなくても、すでに守られています。

ところが、話はそこで終わりません。ブラウザの外で動いているプログラム、たとえばGoで作られたコマンドやサーバー、Tailscaleのような通信ソフト、Linuxの証明書の束、コンテナのイメージ、組み込み機器の中には、今もこの証明書を信じたままのものが残っています。

• この記事では、eMudhraの事件そのものの全体像を、時系列と一次情報をもとに整理します。
• そのうえで、ブラウザ以外の「片付け」が必要な場所として、Go、Tailscale、OSの証明書ストア、コンテナと組み込み機器を中心に、確認の手順まで具体的に書きます。
• Java、Node.js、Pythonについてはそれぞれ別の記事で詳しく扱っているので、この記事では要点の表にとどめます。

先に結論を書いておくと、次の5つです。

何が起きたのか：8枚の中間証明書の秘密鍵を、誰でも計算できた

事件の中身に入る前に、HTTPSの通信を支えている「証明書」の仕組みを簡単に説明しておきます。ここが分かると、なぜ秘密鍵が数字の「4」だったことがこれほど大きな騒ぎになったのかが見えてきます。

認証局・ルート証明書・中間証明書とは

WebサイトをHTTPSで開くと、ブラウザとサーバーの間の通信は暗号化されます。ただ、暗号化だけでは「通信の相手が本当にそのサイトなのか」は分かりません。

そこで、サーバーは「自分はこのドメインの持ち主です」と書かれた電子的な身分証明書を見せます。これがTLS証明書（SSL証明書と呼ばれることもあります）です。

この身分証明書を発行するのが「認証局（CA、Certificate Authority）」です。認証局は、申し込んできた人が本当にそのドメインを持っているかを確かめたうえで、証明書に電子署名をします。

ブラウザやOSは、あらかじめ「この認証局の署名なら信じる」という一覧を持っています。この一覧を「ルートストア」や「証明書ストア」と呼び、一覧に載っている認証局の大元の証明書を「ルート証明書」と呼びます。

ただし、ルート証明書の秘密鍵は認証局にとって最も大切なものなので、ふだんの発行作業には使いません。ルートの下に「中間証明書（中間CA）」を作り、実際のサイトの証明書はこの中間証明書の鍵で署名します。

ブラウザは、サイトの証明書、中間証明書、ルート証明書という順に署名をたどり、最後にルートストアの一覧に行き着けば「信頼できる」と判断します。この鎖のようなつながりを「証明書チェーン」と呼びます。

秘密鍵が「4」：何がどう弱かったのか

問題の8枚は、楕円曲線暗号（ECC）という方式の、P-384と呼ばれる種類の鍵を使っていました。楕円曲線暗号の秘密鍵は、ひとことで言えば「とても大きな乱数」です。

P-384の場合、384ビット、10進数で100けたを超える大きさの数をでたらめに選ぶのが本来の作り方で、その組み合わせは天文学的な数になります。公開鍵は、この秘密鍵から計算で作られますが、逆に公開鍵から秘密鍵を求めるのは、現実の時間ではできないようになっています。

ところが、セキュリティ会社Kudelski Securityのまとめによると、今回の8枚の秘密鍵の実際の値は、4、56、66、115、155、156、230、237でした。Mozillaの分析も、これらの鍵が256未満の整数だったとしています。

秘密鍵の候補が256通りしかなければ、1から256までを順番に試して、公開鍵と一致するものを探すだけで答えが出ます。英国のセキュリティ研究者スコット・ヘルム氏は、公開されている証明書から、自分のノートPCで1秒もかからずに8つすべての鍵を取り出せたと書いています。

この8枚の中間証明書は、作られた日から「秘密鍵が公開されているのとほぼ同じ」状態でした。

ヘルム氏は、ふつう認証局の鍵が漏れたと聞けば盗難を想像するけれども、今回は証明書が存在した最初の日から鍵が事実上公開されていた、という趣旨の指摘をしています。だれかが盗みに入ったわけではなく、最初から鍵がかかっていなかった、という種類の事件です。

問題の8枚はどれか

Kudelski Securityのまとめと、Mozillaのバグ管理システム（Bugzilla）の記録によると、問題の8枚は、2025年4月30日に行われた1回の「鍵生成式（キーセレモニー）」で作られた24枚の中間証明書の一部です。キーセレモニーは、認証局が監査人の立ち会いのもとで、専用の機械（HSM、ハードウェア・セキュリティ・モジュール）を使って重要な鍵を作る正式な手続きのことです。

表のDV・OV・EVは、認証局がどこまで申込者を確かめるかの違いで、DVはドメインの持ち主であることだけ、OVとEVは会社としての実在まで確かめるものです。もうひとつ注目したいのが「クロス署名」です。新しい認証局のルートは、すぐには古い機器のルートストアに入りません。

そこで、すでに広く信頼されている別の認証局に、自分の中間証明書へ署名してもらい、古い機器でもたどれる別ルートを用意します。今回の8枚は、英国の認証局Sectigoの古いルート「AAA Certificate Services（旧Comodo）」からもクロス署名を受けていました。

そのため、同じ8つの鍵に対して、emSign側のルートにつながる証明書と、Sectigo側のルートにつながる証明書の2種類があり、合わせて16枚の証明書が問題になっています。この「16枚」という数字は、あとでJavaやWindowsの対策を読むときに何度も出てくるので、覚えておいてください。

なお、Kudelski Securityのまとめは、Webサイト用のルートを「emSign Root TLS CA – G3」としつつ、利用者向けの説明では「emSign ECC Root CA – G3」を挙げており、名前の書き方が資料の中で揃っていない点を自ら注記しています。ブラウザやOSが実際に信頼を外したのは「emSign ECC Root CA – G3」です。

eMudhraの説明：鍵を作る手順の中で、弱い鍵がもう1組できていた

eMudhraが自社サイトに掲載した声明によると、原因は、キーセレモニーの中の「鍵を包む・取り出す（ラップ／アンラップ）」という手順に欠陥があり、正しく作られた強い鍵とは別に、弱い鍵がもう1組できてしまったことでした。そして、ブラウザなどのルートストアに登録されたのは、その弱いほうの鍵だったと説明しています。

Bugzillaに書き込まれたeMudhraの説明はもう少し具体的で、鍵を作るスクリプト（自動で手順を実行するプログラム）の欠陥でHSMの中に弱い鍵の組ができ、鍵に付けられた名前（ラベル）が正しい鍵と似ていたため、証明書を作る段階で誤って弱いほうを選んでしまった、としています。

承認済みの「テスト用の手順の変更」があったことや、複数の段階で人為的な誤りがあったことも認めています。HSMはFIPS 140-2のレベル3（米国政府の暗号装置の基準）に適合したものを使っていたとしており、装置そのものではなく手順の問題だという立場です。

ただし、eMudhra自身も、根本原因はまだ確定しておらず、調査が終わってから公表するとしています。また、この弱い鍵は2025年半ばに各社のルートストアに入り、2回の独立した監査を通っていました。約18カ月の間、だれにも気づかれなかったことになります。

時系列：10月17日の報告から、27日のChromeのルート削除まで

次に、報告から各社の対応までの流れを、一次情報の時刻で並べます。時刻は協定世界時（UTC）を基本にし、必要なところに日本時間（JST、UTCに9時間を足したもの）を添えています。

表を見ると、ChromeとFirefoxは、報告を受けてから2〜3時間ほどで遮断を終えています。土曜日の夜に届いた報告に、その日のうちに対応したことになります。

一方で、OSやプログラミング言語の対応は、20日から22日にかけて少しずつ出てきました。この「ブラウザは数時間、それ以外は数日から」という差が、この事件のいちばん大事なところです。

資料によって食い違っている点

この事件は短い期間に多くの組織が動いたため、日付や数字が資料によって少しずつ違います。主なものを挙げておきます。

• 失効の日時：Bugzillaには10月18日09:38（UTC）にeMudhraが8枚を失効したと記録されています。eMudhraの会長は「発見から14時間以内に失効した」と述べています。一方で、19日に失効したと読める報道もあります。
• eMudhraの声明の日付：自社サイトの声明は10月20日に初めて掲載され、22日まで更新が続いています。インドの証券取引所向けの発表は21日付です。19日に声明が出たとする二次資料もありますが、一次情報では確かめられませんでした。
• Appleの対応日：19日に出荷したとする資料（Kudelski Security、Help Net Securityなど）と、Mozillaの担当者が中心になってまとめている情報ページの時系列のように22日とするものがあります。AppleとMicrosoftは、この件について独自の告知を出していないとする指摘もあり、日付は第三者のまとめに頼っている状態です。
• Goの公開日：Go公式の告知は10月20日02:11（UTC）で、米国の時間ではまだ19日の夕方です。そのため「19日公開」と書く記事もあります。
• FirefoxのOneCRLの日付：Mozillaのブログは17日22:59（UTC）としていますが、NSSの公開告知の転載には「19日の土曜日」と書かれた箇所があります。10月17日が土曜日なので、ブログの記述を採りました。
• Googleの説明の「8」と「6」：Googleのブログは8枚と6枚の両方の数字を使っています。8枚のうちWebサイト用が6枚で、Chromeの遮断と証明書の透明性の説明は、この6枚について述べたものです。

その後のeMudhra：撤退の発表と、約3万枚の移行

eMudhraはインドのベンガルールに本社を置く会社で、インド国内では電子署名やデジタル署名証明書の大手です。Webサイト用の証明書の事業は「emSign」というブランドで世界向けに行っていました。

Bugzillaへの書き込みによると、問題のG3系のルートからの発行を止めたうえで、移行が必要な証明書はおよそ3万枚、その約97%は自動発行の仕組み（ACME）で入れ替えられる見込みだとしています。

そして10月22日、eMudhraは世界向けのSSL/TLS証明書の事業から撤退すると発表しました。

• 報道によると、この事業は同社の世界全体の売上の約1%で、影響を受ける顧客には提携先を通じて無償で証明書を入れ替えるとしています。
• 株価は21日に1日の値幅制限いっぱいの20%下落となり、2日間で40%下がったとする報道もあります。
• インドの電子情報技術省（MeitY）は調査のための特別チームを作り、国内の電子署名サービスには影響がないと説明しました。
• インドのCERT-In（国のセキュリティ対応チーム）も注意喚起を出しています。

なお、eMudhraの声明では、問題の8枚のうち実際の運用に使われていたのは1枚だけで、7枚は一度も本番で使われておらず、どの1枚からも利用者向けの証明書は発行されていないとしています。影響を受けたのは米国の1社の顧客の環境だとも説明しています。

ただし、これは「eMudhraが正規に発行した証明書」の話です。鍵がだれにでも計算できた以上、eMudhraの知らないところで第三者が証明書を作ったかどうかは、この説明では否定できません。この点は次の節で説明します。

Mozillaは20日にeMudhraへ追加の質問を送りましたが、23日の時点で回答がないとBugzillaに書いています。Googleは、eMudhraの残りの証明書をChromeのルートストアに残すかどうかを検討中としています。今後、対象がさらに広がる可能性があることは頭に入れておいてください。

ブラウザはなぜ数時間で守れたのか：CRLSet・OneCRL・証明書の透明性

今回、ブラウザの利用者がほとんど何もしなくても守られたのには、2つの理由があります。ひとつは、ブラウザの会社が失効の情報を自分で配る仕組みを持っていること、もうひとつは「証明書の透明性（CT）」という仕組みです。

この2つは、ブラウザの外のソフトにはたいてい備わっていないので、なぜブラウザ以外が危ないのかを理解するうえでも大切です。

失効の情報を、ブラウザの会社が直接配る

証明書には有効期限がありますが、期限の前でも「この証明書はもう信じないでください」と取り消すことができます。これを「失効」と呼びます。昔からある失効の仕組みには、認証局が失効した証明書の一覧を公開する「CRL」と、証明書ごとに認証局へ問い合わせる「OCSP」があります。

ただ、どちらも通信のたびに認証局のサーバーへ問い合わせる必要があり、遅い、つながらないと確かめられない、といった弱点がありました。しかも、今回のように認証局の鍵そのものが信用できない場合、その認証局が出す失効情報に頼るのは筋が悪い話です。

そこでChromeは「CRLSet」、Firefoxは「OneCRL」や「CRLite」という独自の仕組みを持っています。どれも、ブラウザの会社が「信じてはいけない証明書」の一覧をまとめ、ブラウザ本体の更新とは別に、裏で自動的に配る仕組みです。

Googleの説明によると、Chromeは今回、中間証明書そのものではなく、その中に入っている公開鍵の指紋（SPKIハッシュ）を対象に遮断しました。こうすると、同じ鍵を使った証明書は、クロス署名版も含めてまとめて拒否できます。利用者はブラウザを更新したり再起動したりする必要がありませんでした。

Androidの端末やGooglebook（Googleのノートパソコン）には、19日の22時（UTC）ごろからGoogle Playサービス経由で同等の更新が届いています。Googleは、端末を再起動すればすぐに受け取れると説明しています。

• Firefoxも同じく、OneCRLは利用者が更新や再起動をしなくても届くと説明しています。
• ただ、会社の管理などでこの自動の仕組みを止めている利用者もいるため、Mozillaは20日に、遮断の情報を本体に組み込んだFirefox 158.0.1、ESR 153.5.1、ESR 115.43.1を出しました。
• Android版では起動直後に一覧の変更がすぐ反映されない問題があり、21日にFirefox for Android 158.0.2で直されています。

証明書の透明性（CT）とは：偽の証明書を「隠れて使えない」ようにする仕組み

もうひとつの守りが「証明書の透明性（Certificate Transparency、CT）」です。これは、認証局が発行したすべての証明書を、だれでも見られる公開の記録帳（CTログ）に書き込ませる仕組みです。

記録帳は追記しかできない作りになっていて、あとから消したり書き換えたりできません。そして、ChromeやSafariなどのブラウザは、CTログに記録された証拠（SCT）が付いていない証明書を受け付けません。

この仕組みがあると、たとえ攻撃者が中間証明書の鍵を手に入れても、ブラウザに信じさせるためには、偽の証明書をCTログに記録しなければならなくなります。

• 記録すれば、世界中の監視者に見つかります。
• 記録しなければ、ブラウザが受け付けません。

どちらに転んでも、ブラウザに対して「こっそり」偽の証明書を使うことはできない、というわけです。

Googleは、遮断の前の時点で、問題の6枚の中間証明書につながるTLS証明書はひとつもCTログに記録されていなかったと説明しています。そのため、CTを確認するクライアント（ChromeやSafari、最新のSDKを対象にしたAndroidアプリなど）に対して、偽の証明書が使われた可能性はないと結論づけています。

Mozillaの担当者らがまとめた情報ページも同じく、主要なブラウザはこの方法で攻撃され得なかったとしています。さらにGoogleは、CTログの側でも、問題の中間証明書につながる証明書を受け付けないよう設定を変えたとしています。

それでもルート証明書まで外した理由

中間証明書を遮断し、eMudhraも失効させたのに、MozillaとGoogleはさらに一歩進めて、その上のルート「emSign ECC Root CA – G3」そのものを信頼の一覧から外す判断をしました。Bugzillaの記録によると、Mozillaは、複数の人が独自に鍵の取り出しに成功し、その一部が公にそれを明かしたことを受けて、緊急でルートの信頼を外したとしています。

ルートを外すことの意味は、ブラウザの外のソフトにあります。CRLSetやOneCRLを受け取らないソフトは、失効の情報を知りません。しかし、ルートストアそのものから大元を外せば、そのルートストアを使っているソフトは、配下の中間証明書をたどっても信頼にたどり着けなくなります。

Mozillaのルートストアは、NSSというライブラリの形で、Linuxの多くのディストリビューションや、さまざまなソフトの証明書の束の元になっています。

Mozillaが20日に公開したNSS 3.131.1は、emSign ECC Root CA – G3に加えて、もともと予定していたemSign Root CA – C1とemSign ECC Root CA – C3の信頼も外しました。Mozillaはこの更新をCVE-2026-113470（Mozillaのアドバイザリー mfsa2026-112）として扱っています。

守られていないのはどこか：ブラウザの外にある「証明書の束」

ここからがこの記事の本題です。ブラウザが守られたのは、先ほどの2つの仕組みがあったからでした。

逆に言えば、この2つを持っていないソフトは、ソフトそのものを更新するまで、問題の中間証明書を信じ続けます。そして、世の中のTLSの通信の多くは、実はブラウザではなく、プログラム同士の通信です。

ブラウザ以外のソフトは、たいてい失効もCTも確かめない

たとえば、サーバーから外部のAPIを呼び出すプログラム、コマンドラインのcurlやgit、パッケージを取ってくるpipやnpm、監視のエージェント、VPNのソフト、スマート家電の中のソフトなどです。

こうしたソフトは、証明書チェーンをたどって「信頼できるルートに行き着くか」は確かめますが、CRLやOCSPで失効を確かめることは少なく、CTの証拠を確かめるものはさらに少数です。Mozillaの担当者がまとめた情報ページも、curlを含むブラウザ以外の多くのクライアントはCTを確認しないと注意しています。

そのため、こうしたソフトにとって、今回の8枚の中間証明書は、ルートストアから大元が外れるまで「正規の中間証明書」のままです。攻撃者が問題の鍵で好きなドメインの証明書を作り、通信の途中に割り込めば、そのソフトは偽のサーバーを本物だと思い込んで通信してしまう可能性があります。

送ったパスワードやAPIキーを読まれたり、受け取るデータを書き換えられたりするおそれがある、ということです。

悪用には「通信の途中に割り込める立場」が必要

また、報道によると、SignalやWhatsApp、WireGuardのように、TLSの証明書に頼らず独自の仕組みで相手を確かめているものは影響を受けません。Tailscaleも、端末同士の通信そのものはWireGuardの鍵で守られているため影響がないとしています（後で詳しく書きます）。

ブラウザの外で、更新が必要になるものの一覧

では、具体的にどこを更新すればよいのでしょうか。Mozillaの担当者デニス・ジャクソン氏が中心になって公開している情報ページ（コミュニティの協力で更新されています）や、Kudelski Security、Cloudflareの説明をもとに、更新が必要になる場所を分類すると次のようになります。

Electronは、Webの技術でパソコン用のアプリを作るための土台です。Electronのアプリは中にChromiumの一部を抱えていますが、CRLSetのようなブラウザの仕組みまでは持っていないことが多く、情報ページによると、Electron 44.9.1、43.8.1、42.11.16に上がったアプリでないと直りません。

また、macOSに最初から入っているcurlは失効を確認しないため、問題の証明書を受け付けてしまう可能性があるとKudelski Securityは注意しています。Safariが守られていても、同じMacのターミナルで動くcurlは別、ということです。

Sectigoのクロス署名が、片付けを難しくしている

もうひとつ、片付けを面倒にしているのが、先ほど書いたSectigoのクロス署名です。Sectigoの書き込みによると、AAA Certificate Servicesというルートは、ChromeとMozillaのルートストアからはすでに外れていますが、MicrosoftとAppleのストアにはまだ残っています。Javaの証明書ストアや、古いLinuxのストアにも残っているものがあります。

この状態で、emSign ECC Root CA – G3だけを外しても、クロス署名版の中間証明書を使えばAAA Certificate Servicesにたどり着けてしまいます。かといって、AAA Certificate Servicesまで外すと、このルートにつながっている無関係の正規のサイトまで使えなくなるおそれがあります。

Sectigoはクロス署名版を失効させましたが、失効を確かめないソフトには意味がありません。そのため、Javaの対策では、ルートを消すのではなく、問題の16枚を「拒否リスト」に入れる方法が勧められています。

UbuntuやDebianは、古い版向けの更新でAAA Certificate Services（パッケージ上の名前は「Comodo AAA Services root」）も外しました。自分の環境でどちらの方法が取られたのかは、使っているOSや実行環境の告知で確かめる必要があります。

Go：1.27.3と1.26.10の拒否リストと、作り直しが必要な理由

ブラウザ以外で最も早く手を打ったのが、Googleが中心になって開発しているプログラミング言語Goです。

Goはサーバーのプログラムやコマンドラインの道具でとても広く使われていて、Docker、Kubernetes、Terraform、Tailscale、cloudflaredなど、名前を聞いたことのある多くの道具がGoで書かれています。そのため、Goの対応は、それらの道具すべての対応の前提になります。

修正の中身：CVE-2026-111943

Goチームは10月20日（UTC）、Go 1.27.3とGo 1.26.10を公開しました。告知によると、この版に含まれるセキュリティの修正は1件だけで、題名は「crypto/x509: mitigation for security concerns with a specific Certificate Authority（特定の認証局に関するセキュリティ上の懸念への緩和策）」です。crypto/x509は、Goの標準ライブラリの中で証明書を検証する部分です。

告知とGoの課題管理（issue 82345）の説明は、「運用に関する特定のセキュリティ上の懸念から、少数の中間証明書への信頼を止める」「Verifyは、これらの中間証明書を含むチェーンを取り除き、呼び出し元に返さない」というものです。つまり、Goのプログラムが証明書を検証するとき、問題の中間証明書を通るチェーンは、たとえOSの証明書ストアがまだ信頼していても、検証に通らなくなります。番号はCVE-2026-111943で、Goチームは「すぐに更新することを強く勧める」としています。

なお、Goの告知そのものは、認証局の名前も、対象の枚数も書いていません。この修正がeMudhraの8枚を対象にしたものだというのは、Tailscaleの公報などの第三者による説明と、時期の一致によるものです。Tailscaleの公報は、Go 1.27.3が問題の証明書を明示的に信頼しないようにしており、システムの証明書ストアにまだ残っていても効く、と説明しています。

なぜ「作り直し」が必要なのか

Goの特徴は、プログラムを1つの実行ファイルにまとめて配れることです。この実行ファイルの中には、Goの標準ライブラリ、つまりcrypto/x509のコードも一緒に焼き込まれています。

そのため、開発用のパソコンでGoを1.27.3に上げても、すでに作ってサーバーに置いてある実行ファイルの中身は変わりません。新しい拒否リストを効かせるには、修正版のGoでプログラムをビルドし直し、その実行ファイルを配り直す必要があります。

これは、自分で書いたプログラムだけの話ではありません。Goで作られた道具を使っているなら、その道具の作者が修正版のGoでビルドし直した新しい版を出し、それを自分が入れるまで、道具の中の検証は古いままです。後で書くTailscaleやcloudflaredが新しい版を出したのは、このためです。

もうひとつ知っておきたいのは、Goが証明書の一覧をどこから読むかです。一般に、Linuxで動くGoのプログラムは、OSの証明書の束（たとえば/etc/ssl/certs/ca-certificates.crt）を読みます。WindowsやmacOSでは、OSの検証の仕組みを使います。

つまり、Goのプログラムを作り直す前でも、OSの証明書ストアからemSign ECC Root CA – G3が外れていれば、emSign側のチェーンは通らなくなります。ただし、SectigoのAAA Certificate Servicesがストアに残っている環境では、クロス署名側のチェーンが通ってしまう可能性があります。Goの拒否リストは、この穴をプログラムの側で塞ぐものだと考えると分かりやすいでしょう。

Go 1.25以前には修正がない

Goは、最新の2つのメジャー版だけを保守する方針を取っています。今の保守対象は1.27系と1.26系で、課題管理の記録を見ても、修正が移植されたのはこの2つだけです。Rescanaのまとめも、1.25以前には修正がないとしています。

1.25以前でビルドしたプログラムを使い続けている場合は、まず1.26.10以上か1.27.3以上でビルドし直すことを考えてください。古いGoでしかビルドできない事情があるなら、少なくとも動かす環境のOSの証明書ストアを最新にしておくことが最低限の対策になります。

自分のGoのプログラムを確かめる手順

手元とサーバーで確かめることを、順に書いておきます。

1. ビルドに使っているGoの版を確かめます。開発用のパソコンとCI（自動でビルドする仕組み）のサーバーの両方でgo versionを実行し、1.27.3以上か1.26.10以上になっているかを見ます。開発用のパソコンだけ上げて、CIのビルド用イメージが古いままという食い違いがよくあります。
2. すでにある実行ファイルが、どの版のGoで作られたかを確かめます。go version ./myappのように実行ファイルを指定すると、ビルドに使ったGoの版が表示されます。go version -m ./myappとすると、取り込んでいるモジュールの一覧まで見られます。サーバーに置いてある実行ファイルや、Goで作られた市販・オープンソースの道具にも使えます。
3. go.modのgo行とtoolchain行を見直します。toolchain go1.27.3のように書いておくと、古いGoが入った環境でも、必要な版のツールチェーンを取ってきてビルドするよう指定できます。
4. Dockerでビルドしている場合は、FROM golang:1.27.2のように古い版を固定していないかを確かめ、golang:1.27.3以上に上げます。
5. ビルドし直したら、実際に動いている場所に配り直し、プロセスを再起動します。古いプロセスが動いたままでは意味がありません。

Goの脆弱性を調べる公式の道具govulncheckは、標準ライブラリの脆弱性も、ビルドに使ったGoの版から判定します。Goの脆弱性データベースにこの件が登録されていれば、govulncheck ./...や、実行ファイルを対象にしたgovulncheck -mode=binary ./myappで、対応が必要なものを洗い出す助けになります。登録の状況は、実行したときの出力で確かめてください。

Tailscaleとcloudflared：Goで作られた通信の道具は、更新の確認を

Goの修正が実際の道具にどう届いたのかを、身近な例で見てみます。自宅のNASや小さなサーバーに外からつなぐために、TailscaleやCloudflare Tunnelを使っている人は多いと思います。どちらもGoで作られていて、今回の件で新しい版が出ています。

Tailscaleの公報TS-2026-013

Tailscale（テイルスケール）は、自分の持っているパソコンやスマホ、サーバーを、どこにいても同じ社内ネットワークのようにつなげるVPNのサービスです。端末同士の通信には、WireGuardという仕組みを使っています。

Tailscaleは10月21日、セキュリティ公報TS-2026-013を出しました。内容を要約すると、次の3点です。

• eMudhraが所有する8枚のTLS中間証明書の秘密鍵が漏れたこと
• 攻撃者はその鍵で自分の持っていないサイトの証明書を発行でき、問題の中間証明書を信頼している端末は警告なしにそれを受け入れてしまうこと
• Tailscaleのクライアントとサーバーは、TLSの検証にホストの証明書ストアを使うため、ストアに問題の中間証明書が残っている端末が影響を受けること

対策として、Tailscale v1.104.2以降はGo 1.27.3を使ってビルドされていて、システムの証明書ストアに問題の証明書が残っていても明示的に信頼しない、と説明しています。利用者がやることは、v1.104.2以降に更新することです。Tailscale社自身も、社内のサービスをGo 1.27.3に上げ、サーバーの証明書ストアを更新したとしています。

大事な点として、Tailscaleは、端末同士の通信はTailscaleの端末の鍵を使ったWireGuardで暗号化されていて、Webの証明書の仕組みやシステムの証明書ストアには頼っていないため、影響を受けないとしています。つまり、自宅のNASとスマホの間の通信が今回の件で読まれる、という話ではありません。影響を受けうるのは、Tailscaleが外部のサーバーとTLSでやりとりする部分です。

公報は、それがどの通信なのかを個別には書いていないので、ここでは「TLSでつなぐ部分全般」と理解しておくのが安全です。深刻度の点数も公報には書かれていません。

Tailscaleの版を確かめて更新する

手元の端末でtailscale versionを実行すると、入っている版が表示されます。1.104.2より古ければ更新します。更新のやり方は端末によって違います。

• WindowsとmacOS：Tailscaleのアプリの更新、またはApp Storeなどの配布元から更新します。設定で自動更新を有効にしている場合は、版が上がっているかだけを確かめます。
• Linux：公式のパッケージの置き場所を登録しているなら、sudo apt update && sudo apt install tailscaleのように、ふだんのパッケージの更新で入ります。公式の手順で入れた環境ではsudo tailscale updateも使えます。
• スマホ：App StoreやGoogle Playから更新します。
• NASやルーター：SynologyやQNAPのパッケージ、ルーター向けの配布物などで入れている場合は、その配布元が新しい版を出すまで時間がかかることがあります。パッケージの版を確かめ、古いままなら配布元の案内を待つか、公式の手順での更新を検討します。
• Docker：tailscale/tailscaleのイメージを使っているなら、版を指定して取り直し、コンテナを作り直します。

Tailscaleの管理画面では、つながっている端末ごとの版を一覧で見られます。家族の端末や、置きっぱなしの小さなサーバーまで含めて、古い版が残っていないかを一度見ておくと安心です。

Cloudflareの各クライアントとcloudflared

Cloudflareも、10月19日の17時（UTC）ごろにこの件を把握し、利用者向けのアプリを更新しました。公式ブログで示された修正版は次のとおりです。

cloudflaredは、自宅や社内のサーバーを、ポートを開けずにCloudflare経由で公開するための道具です。cloudflared --versionで版を確かめ、2026.10.2より古ければ更新します。コンテナで動かしている場合は、修正版のイメージを取り直して配り直す必要があるとCloudflareは書いています。

Cloudflareのブログには、ほかにも利用者向けの大事な指摘があります。

• Cloudflareの「Full (strict)」や「Strict」の設定で、Cloudflareから自分のサーバー（オリジン）への通信の証明書を厳しく確かめている場合は、オリジンの証明書の構成を見直すよう求めています。
• 相互TLS（mTLS、接続してくる側の証明書も確かめる方式）で使う信頼の一覧や、アップロードしたCAの見直しも挙げています。
• また、SDK（サービスを呼び出すための部品）を更新しても、実際の証明書の確認がHTTPのライブラリや言語の実行環境、OSに任されている場合は、それだけでは直らないと注意しています。

TailscaleとCloudflareの例から分かるのは、Goで作られた通信の道具は、その道具が新しいGoでビルドし直されて初めて直る、ということです。自分のパソコンやサーバーに入っているGo製の道具を思い浮かべて、更新の告知が出ていないか確かめてみてください。

OSの証明書ストア：Linux・Windows・macOS・Androidの状況

多くのプログラムは、自分で証明書の束を持たず、OSの証明書ストアを使います。そのため、OSの証明書ストアを更新するのは、ブラウザ以外の片付けの土台になります。ここでは、主なOSの状況と、確かめ方をまとめます。

主なOSの対応状況

下の表は、各OSの公式の告知と、Mozillaの担当者らがまとめている情報ページをもとにしたものです。情報ページはコミュニティの協力で更新されている二次的なまとめなので、自分の環境については、それぞれの配布元の告知で確かめてください。

表のとおり、主なLinuxは20日から数日のうちに更新を出しています。気をつけたいのは、macOSの/etc/ssl/cert.pemです。

これは、Safariなどが使うmacOSの本来の仕組みとは別の、OpenSSLやcurlのようなUnix系の道具が読む証明書の束です。情報ページによると、Appleは今後の更新でこのファイルを直すとしており、それまでの間、このファイルを読む道具は問題の証明書を信じる可能性があります。

Linuxで確かめる手順

DebianやUbuntuでは、次の順で確かめられます。

1. sudo apt update && sudo apt install --only-upgrade ca-certificatesで、証明書の束のパッケージを更新します。
2. dpkg -l ca-certificatesで、入っている版が表の修正版以上になっているかを確かめます。
3. ls /etc/ssl/certs | grep -i emsignを実行し、emSign_ECC_Root_CA_-_G3.pemという名前が出てこないことを確かめます。他のemSignのルートは残っていても問題ありません。
4. Javaを使っていて、OSの証明書ストアからJava用のストアを作る仕組み（ca-certificates-java）を入れている場合は、Java側にも反映されているかを確かめます。

Red Hat系（RHEL、Fedora、Rocky Linux、AlmaLinux、Amazon Linux 2023など）では、sudo dnf upgrade ca-certificatesでパッケージを更新し、trust list | grep -i -A2 emsignで、emSign ECC Root CA – G3が信頼の一覧に残っていないかを確かめます。Alpineではapk upgrade ca-certificatesです。

情報ページには、配布元の更新が来ていない場合に、自分でルートの信頼を外す方法も載っています。たとえばDebianやUbuntuでは/etc/ca-certificates.confの該当行を無効にしてupdate-ca-certificatesを実行する、Red Hat系ではブロックリストの置き場所に証明書を置いてupdate-ca-trustを実行する、といった手順です。ただし、情報ページ自身が「普通の利用者には勧めない」と書いており、AAA Certificate Servicesまで外すと無関係のサイトが使えなくなるおそれもあります。

配布元の更新が出ているなら、それを入れるのが基本です。自分で外すのは、更新が出ない古い環境で、影響を理解したうえでの最後の手段と考えてください。

WindowsとmacOSで確かめる

Windowsは、証明書の信頼の一覧をWindows Update経由で自動的に更新する仕組みを持っています。会社の管理などでこの自動更新を止めていなければ、特別な操作は要らないはずです。ふだんどおりWindows Updateを最新にしておいてください。

情報ページには、問題の証明書をWindowsの「信頼されていない証明書」に入れるPowerShellのスクリプトも載っていますが、会社で管理されているパソコンでは使わず、まず社内のIT担当に相談するよう書かれています。

macOSとiOSは、OSを最新にしておくのが基本です。そのうえで、Macのターミナルでcurlや古いPythonのpip3などを使う人は、それらが/etc/ssl/cert.pemや自前の証明書の束を読んでいる点に注意してください。HomebrewでOpenSSLやcurlを入れている場合は、Homebrewのca-certificatesが更新済みとされているので、brew update && brew upgradeで上げておきます。

Androidで確かめる

Androidは、Google Playサービスの更新で遮断が届きます。Googleは、再起動すればすぐに受け取れるとしているので、気になる人は一度再起動しておくとよいでしょう。

Google Playサービスが入っていない端末や、更新が来ない古い端末では、「設定」の「信頼できる認証情報」の「システム」から、「emSign ECC Root CA – G3」と「AAA Certificate Services」を無効にする方法が情報ページに載っています。ただし、端末によってはこの操作ができないものもあり、AAA Certificate Servicesを無効にすると他のサイトに影響が出る可能性もあります。

コンテナと組み込み機器：開発機を直しても、本番は直らない

Go のcrypto/x509の開発に関わるフィリッポ・ヴァルソルダ氏は、今回の片付けについて「Heartbleedより大きな片付けになる」と話し、IoT機器、Dockerのコンテナ、忘れられたLinuxのマシンといった「とても長い尻尾」が残ると警告しました。

Heartbleedは、2014年に見つかった、暗号のライブラリOpenSSLの深刻な欠陥で、世界中のサーバーが証明書の作り直しに追われた事件です。この発言は、The Next Webの記事ではArs Technicaの取材に答えたものと紹介されており、TechCrunchも10月21日の記事で、セキュリティの専門家の言葉として「Heartbleedより大きい」という表現を引いています。

この「長い尻尾」の中で、開発者がいちばん見落としやすいのがコンテナです。

コンテナのイメージは、作った時点の証明書の束を抱えている

Dockerなどのコンテナのイメージは、OSの最小限のファイルとアプリをひとまとめにした配布物です。この中には、イメージを作った時点の/etc/ssl/certsや、アプリが取り込んだcertifiなどのライブラリ、JavaならJDKに入っているcacertsが、そのまま固められています。

そのため、ホストのLinuxでca-certificatesを更新しても、コンテナの中の証明書の束は変わりません。コンテナの中のプログラムは、イメージの中の古い一覧を見て検証します。

さらに厄介なのは、Dockerのビルドの「キャッシュ」です。Dockerは、前に作った層（レイヤー）が使えると判断すると、それを使い回して速くビルドします。

apt-get install ca-certificatesを実行する層がキャッシュされていると、ビルドし直したつもりでも、古い証明書の束が入ったままのイメージができあがります。ベースイメージも、手元に古いものが残っていれば、それが使われます。

コンテナの片付けの手順

1. ベースイメージを新しく取り直します。docker build --pull --no-cache -t myapp:fixed .のように、--pullでベースイメージを取り直し、--no-cacheでキャッシュを使わずにビルドします。
2. Dockerfileの中で、OSのパッケージを更新する手順があるかを確かめます。DebianやUbuntuが土台なら、apt-get update && apt-get install -y --only-upgrade ca-certificatesを入れておくと、ベースイメージの更新を待たずに新しい束を入れられます。
3. できあがったイメージの中を確かめます。シェルのあるイメージなら、docker run --rm --entrypoint sh myapp:fixed -c 'ls /etc/ssl/certs | grep -i emsign'で、emSign ECC Root CA – G3の名前が残っていないかを見ます。
4. 言語ごとの証明書の束も確かめます。Pythonならcertifiの版、Node.jsなら実行環境の版、JavaならJDKの版、Goならビルドに使ったGoの版です（次の節の表を参照）。
5. 新しいイメージを、実際に動いている場所に配り直します。Kubernetesなら、イメージのタグを更新して配り直すか、同じタグを使っているならkubectl rollout restart deployment/myappで作り直させます。ただし、同じタグを上書きする運用では、ノードに古いイメージが残っていると使われることがあるので、新しいタグを付けるほうが確実です。
6. CIのビルド用のイメージや、ビルドの途中で使う道具のイメージも見直します。Rescanaのまとめは、Dockerfileでuvのイメージを古いタグに固定している場合は0.13.5以降に上げるよう挙げています。

「distroless」や「scratch」のように、シェルもパッケージ管理も入っていない最小のイメージを使っている場合は、特に注意が必要です。こうしたイメージでは、ビルドの段階で別のイメージから/etc/ssl/certs/ca-certificates.crtをコピーして入れていることが多く、そのコピー元が古ければ古い束が入ります。Goのプログラムをscratchのイメージに入れている場合は、Goの版と、コピーしてきた証明書の束の両方を新しくする必要があります。

組み込み機器・アプライアンス・社内の装置

コンテナよりさらに直しにくいのが、自分では中身を触れない機器です。次のような機器は、メーカーが作った時点の証明書の束を持っていて、メーカーが更新を出さない限り変わりません。

• ネットワークのプロキシ、ロードバランサー、VPNの装置、セキュリティの検査装置
• NAS、監視カメラ
• 工場やビルの制御装置
• スマート家電

Kudelski Securityのまとめも、こうした機器については、自分でストアを変えられない場合はメーカーに更新を求めるよう勧めています。

特に気をつけたいのは、社内の通信を検査するプロキシや、外部のサービスへの通信をまとめる装置です。こうした装置が外部のサーバーの証明書を確かめる役を担っている場合、装置が古い一覧のままだと、その後ろにいるすべての端末が影響を受けます。社内のIT担当の方は、自社の装置のメーカーから告知が出ていないか、出ていなければいつ出るのかを確かめておくとよいでしょう。

一方で、すべての機器が同じように危ないわけではありません。悪用には通信の途中に割り込める立場が必要なので、外部と通信しない機器や、特定のサーバーの証明書を固定して確かめている機器は、影響が小さいと考えられます。また、そもそもemSignのルートを最初から持っていない古い機器もあります。

ただし、AAA Certificate Servicesは古くからある広く使われたルートなので、古い機器ほどクロス署名側のチェーンを信じてしまう可能性があります。「古いから大丈夫」とは言い切れない点に注意してください。

実際の通信経路で確かめる

Cloudflareは、確認するときは実際にアプリが使っているTLSの経路で確かめるよう強調しています。ブラウザでのテストに合格しても、裏で動いているサービスが守られている証拠にはなりませんし、curlでのテストは、別の検証の仕組みを使うアプリには当てはまりません。

情報ページには、問題の中間証明書で作ったテスト用の証明書を使ったサイトが用意されています。たとえばcurl https://dv-g3b-emudhra.we-have-a-problem.com/と、Sectigoのクロス署名側を使うcurl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/です。

これらが証明書のエラーで失敗すれば、その道具は問題の中間証明書を拒否していることになります。名前に「noct」が付いたテスト用のサイトは、CTに記録されていない証明書を使っており、ここにつながってしまう場合は、問題の中間証明書を信じていて、しかもCTも確かめていないことを意味します。

この方法は、curlだけでなく、自分のアプリの中から同じURLに接続してみることで、アプリの実際の経路を確かめるのにも使えます。ただし、テスト用のサイトはあくまで第三者が用意したもので、その中身を独立に検証したものではないとKudelski Securityは注意しています。テストの結果は参考として扱い、最終的には各ソフトの告知と版の確認で判断してください。

Java・Node.js・Pythonの要点と、立場別にやること

Java、Node.js、Pythonは、それぞれ自分の証明書の束を持っていたり、OSの束を独自の方法で読んだりするため、個別の対応が必要です。詳しくはこのブログのそれぞれの関連記事で扱っているので、ここでは要点だけを表にまとめます。版の数字は各公式の告知や、Mozillaの担当者らの情報ページによるものです。

表の中で特に覚えておきたいのは、Javaの「AAA Certificate Servicesが残っている」点と、Pythonの「certifiの固定」です。どちらも、OSを更新しただけでは直らない典型例です。

また、Pythonについては、CPython 3.9と3.10が同梱しているpipは問題のルートを信じる版のままで、それらから作った仮想環境（venv）は、中でpipを上げない限り古いままだとAstral（uvの開発元）が説明していると、Rescanaのまとめは紹介しています。

立場別にやること

ここまでの内容を、立場ごとに整理しておきます。全部を一度にやる必要はありません。自分に関係する行から順に手を付けてください。

Webサイトの運営者が自分の証明書を確かめるには、openssl s_client -connect example.com:443 -showcertsのように自分のドメインを指定して接続し、表示される証明書チェーンの中に「emSign ECC Root CA – G3」や「EM DV TLS CA – G3B」のような名前がないかを見ます。ブラウザのアドレスバーの表示から証明書の詳細を開いて、発行者の名前を確かめる方法でも構いません。

日本の個人や中小のサイトでemSignの証明書を使っている例は多くないと思われますが、海外のサービス経由で証明書を取っている場合などは、念のため確かめておくと安心です。

仕組みを体系的に学びたい人へ

今回の事件は、証明書チェーン、クロス署名、失効、CTといった、ふだんは意識しない仕組みが一度に表に出てきた出来事でした。これを機にTLSと証明書の仕組みを基礎から押さえておきたい人には、次の本が参考になります。

プロフェッショナルTLS＆PKI 改題第2版をAmazonで見る

出版社のラムダノートの紹介によると、次のような特徴があります。

• 原著はIvan Ristić氏の『Bulletproof TLS and PKI, 2nd Edition』で、齋藤孝道氏が監訳した日本語版です。B5判488ページ、2023年12月の刊行です。
• インターネットのPKI（公開鍵基盤）を扱う章で、証明書チェーン、認証局、証明書のライフサイクル、PKIの弱点と改善の取り組みを説明しています。今回の「中間証明書」や「クロス署名」の背景を理解するのに役立ちます。
• 失効（CRLやOCSP）、Webにおける証明書の失効、Certificate Transparency（CT）、CAAといった、今回の事件で出てきた仕組みの節があります。
• プロトコルやPKI、実装を破ってきた脆弱性や事件と、それに研究者や業界がどう対応してきたかの話をまとめています。
• OpenSSLを使ったテストの方法や、サーバーの設定の手引きなど、実務で手を動かすための内容も含まれています。

まとめ

eMudhraの事件は、インドの認証局が2025年4月に作った中間証明書8枚の秘密鍵が、手順の誤りによって256通り以下しかない状態で作られ、約1年半そのまま信頼されていた、というものでした。10月17日の報告から数時間でChromeとFirefoxが遮断し、AppleとMicrosoft、そしてGo、Mozilla、各Linuxが続きました。

CTの記録から、主要なブラウザに対して偽の証明書が使われた可能性はないとされており、10月24日の時点で悪用は確認されていません。eMudhraは世界向けのSSL/TLS証明書の事業から撤退すると発表しています。

一方で、ブラウザのような失効の自動配信やCTの確認を持たないソフトは、更新するまで問題の中間証明書を信じ続けます。しかもSectigoのクロス署名があるため、ルートを1つ外すだけでは足りない環境もあります。

悪用には通信の途中に割り込める立場が必要なので、むやみに怖がる必要はありませんが、片付けは確実に進めておく必要があります。

• ブラウザとOSは最新に。Androidは一度再起動する
• Goは1.27.3か1.26.10以上でビルドし直し、配り直す（1.25以前には修正がない）
• Tailscaleはv1.104.2以降、cloudflaredは2026.10.2以降にする
• Linuxのca-certificatesを更新し、コンテナは--pull --no-cacheで作り直して配り直す
• Java、Node.js、Pythonは、それぞれの実行環境と証明書の束を修正版にする
• 確認は実際の通信経路で行い、エラーが出ても証明書の検証は無効にしない

今回の件で改めて分かったのは、「インターネットの信頼」が、ブラウザの会社の素早い対応だけで成り立っているわけではないということです。サーバーの中、コンテナの中、機器の中にある無数の証明書の束を、ひとつずつ新しくしていく地道な作業が、これからしばらく続きます。自分の手の届く範囲から、ひとつずつ確かめていきましょう。

出典

• Mozilla Security Blog Protecting Firefox users following the compromise of eMudhra intermediate certificates
• Mozilla Bugzilla Bug 2083449 eMudhra: Private key compromise of Intermediate Certificates
• oss-security NSS 3.131.1 release（Mozilla dev-tech-crypto の転載）
• Google Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates
• eMudhra Statement on Recent Certificate Security Incident
• eMudhra Intermediate CA Compromise（Dennis Jackson氏らによる情報ページ）
• oss-security Go 1.27.3 and Go 1.26.10 are released（Go公式アナウンスの転載）
• golang/go issue 82345 crypto/x509: mitigation for security concerns with a specific Certificate Authority
• Tailscale Security Bulletins（TS-2026-013）
• Cloudflare 8 eMudhra certificates are compromised. Here’s what you need to know
• OSV USN-8944-1 ca-certificates update（Ubuntu）
• OSV USN-8944-2 ca-certificates update（Ubuntu）
• Node.js October 2026 Security Releases
• PyPI certifi
• Kudelski Security eMudhra Intermediate CA Private Key Compromise
• Rescana eMudhra Intermediate CA Key Compromise October 2026
• Guillaume Laforge The eMudhra CA compromise: why your JVM is vulnerable and how to fix it
• Help Net Security eMudhra security blunder left trusted CA signing keys exposed to anyone
• The Next Web Eight eMudhra certificate keys were so weak that one was the number 4
• TechCrunch The internet is having a very bad cybersecurity day
• Business Standard eMudhra to exit global SSL/TLS certificate business after security flaws
• ThePrint MeitY sets up team to probe eMudhra certificate breach
• ラムダノート プロフェッショナルTLS＆PKI 改題第2版

※この記事の内容は、2026年10月24日時点で公表されている情報をもとにしています。