鍵は4だった――あなたのソフトウェアが信頼するウェブサイトを決めるのは誰か

これは機械翻訳された記事です。原文は英語です。

最終更新日：2026年10月25日 · 読了時間22分

ここに問題がある

2026年10月17日土曜日、UTC 18時05分、Chromeのルートプログラムに一通の報告が届いた。送り主は、公にはウェインという名でしか知られていないセキュリティ研究者である。彼は、インドのベンガルールに本社を置く上場企業eMudhraが運用する8つの認証局の秘密鍵を持っていると主張した。それを証明するために、彼は8つの鍵それぞれで、「ここに問題がある――ウェイン」という同じ短いメッセージに署名していた。

彼は何かに侵入する必要すらなかった。ニュースが広まると、セキュリティ研究者のスコット・ヘルムが、鍵がどんなものだったかを明かした。そのひとつは、ただの数字の4だった。ほかの二つは56と115である。ヘルムによれば、彼は自分のノートパソコンで、公開されている証明書からすべての鍵を復元し、それにかかった時間は1秒に満たなかったという。記者による独自の検証でも、eMudhraの「EM OV TLS CA – G3C」の背後にある秘密鍵が4であることが確かめられた。

8つはいずれも中間CA、つまり証明書事業者のなかで、他者のための証明書に署名する実務の層だった。そのうち6つはウェブサイト向けの証明書を発行する権限を持ち、この6つはChrome、Mozilla、Microsoft、Appleのルートプログラムから信頼されていた。残りの2つはコード署名用、すなわちソフトウェアメーカーが自社のプログラムに署名するための証明書で、Microsoftから信頼されていた。これらの鍵は誤った方法で生成されていたため、どこを見ればよいかを知る者なら誰でも、そもそも公開を前提とする証明書そのものから鍵を計算できた。それは2025年4月に証明書が作成されたときから可能だった。

報告の到着から1時間40分後のUTC 19時45分には、Chromeは調査結果を確認し、ユーザーにブロックを配信していた。アップデートをインストールする必要も、ブラウザーを再起動する必要も、誰にもなかった。

速さが重要だったのは、こうした鍵で何ができるかを考えればわかる。6つのウェブサイト用の鍵のどれかを持ち、相手の通信を傍受できる者は、銀行でもメールサービスでも、どんなサイトの偽造証明書でも提示できた。本物のサイトがどの証明書事業者を使っていようと関係はなく、eMudhraのチェーンを信頼するソフトウェアはそれを受け入れてしまう。立ちはだかる防御は主に二つあった。一つはCertificate Transparencyと呼ばれる公開の記録の仕組みで、これを必須とするソフトウェアもあるが、多くはそうではない。もう一つは、各ソフトウェアが間に合うように受け取ったブロックである。

偽造証明書が通用したかどうかは、ふだんは目に見えない判断にかかっていた。誰がウェブサイトの身元を保証するのか、その保証人を信じるべきだと誰が決めるのか、そして保証人が壊れていると判明したとき、その信頼をどれだけ速く撤回できるのか、という判断である。

証明書は何を保証するのか

ウェブサイトの証明書は、銀行のウェブアドレスのような名前を公開鍵と結びつける、署名入りの小さな文書である。公開鍵は秘密鍵と対になっている。秘密鍵は秘密に保たれ、デジタル署名を生み出す。公開鍵を使えば、署名が対になる秘密鍵から生まれたものかどうかを誰でも確かめられる。ブラウザーがサイトに接続すると、サイトは自分の証明書にある公開鍵と対応する秘密鍵を持っていることを証明する。証明書そのものは、この公開鍵がこの名前のものだと述べており、認証局（CA）がその言明に署名することで後ろ盾となる。

CAはウェブサイトの証明書に署名する前に、申請者がそのドメインを管理していることを確認しなければならない。認められた方法の一つは、申請者にランダムな値を渡し、インターネットの公開住所録であるDNSレコードのうち、そのドメインを管理する者にしか書き込めないはずの場所にその値があるかを確かめるというものである。CAはまた、所有証明（proof of possession）と呼ばれる技術的なテストによって、申請者が認証を求める秘密鍵を本当に持っているかを確認することもできる。もっとも、根拠となる標準規格は、申請者の申告に頼ることも認めている。

世界中のCAをブラウザーが自力で一つ残らず確かめることはできない。そこで信頼は、連鎖のかたちで委ねられる。頂点にあるのはルート証明書で、オペレーティングシステムやブラウザーに同梱されるルートストアと呼ばれる一覧に収められている。ルートが中間CAに権限を与え、中間CAがウェブサイトの使う証明書を発行する。ソフトウェアはサイトの証明書を見ると、署名をサイトから中間CA、そしてルートへとさかのぼってたどる。そしてチェーンが自分のストアにあるルートで終わり、すべての署名が正しく検証でき、証明書が有効期間内でアクセス先の名前を対象としており、ソフトウェアのほかのどの規則にも禁じられていない場合に限って、そのサイトを受け入れる。

ルートプログラムは、Apple、Google、Microsoft、Mozillaといったオペレーティングシステムやブラウザーのベンダーが運営しており、認証局を審査して、どのルートをストアに入れるかを決める。中間CAの秘密鍵がこれほど価値を持つのはそのためだ。中間CAは、特定の名前に制限されていない限り、どのドメインの証明書にも署名でき、その証明書は信頼されたルートまでさかのぼって検証される。eMudhraの中間CAには、その制限がなかった。ルート自身の鍵は厳重にしまい込んでおける。日々の署名を担うのは中間CAの鍵であり、それが漏れれば、ルートのお墨付きも一緒に漏れる。

ブラウザーの鍵アイコンはそれを示すものと広く受け取られているが、ここまでの仕組みのどれも、ウェブサイトが誠実かどうかは教えてくれない。2021年にGoogleがこの問題を調べたとき、鍵アイコンの意味を正しく理解していた参加者はわずか11%だった。しかもフィッシングサイトのほぼすべてがHTTPSを使っており、したがって鍵アイコンを表示していた。2023年、GoogleはChromeの鍵アイコンを別のアイコンに置き換えると発表した。基本的な証明書が示すのは、その名前の鍵を持つ者に接続がつながっているということだけである。サイトの背後にある組織の名前まで記した証明書もあるが、その意図を保証する証明書は一つもない。

もう一つ層がある。2013年にGoogleのエンジニアたちが定めたCertificate Transparencyは、証明書を公開ログに載せ、各CAが何を発行したのかを誰でも監査できるようにする。設計者たちは、いずれクライアントがログに記録されていない証明書をすべて拒否するようになることを意図していた。そうなれば、ログの外に置かれた証明書は、CAが発行したものであれ、CAの鍵を手にした盗人が作ったものであれ、拒否される。Chromeは、自らのルートストアに依拠するすべての接続で、これを標準で実施している。

顧みられなかった警告

CAの鍵の作り方をめぐる規則は厳格である。ブラウザーのルートプログラムとCAが共同で維持する業界の規則集、Baseline Requirementsは、ルートと一部の中間CAの鍵について、CAが文書化された鍵生成スクリプトに従い、資格を持つ監査人をキーセレモニーに立ち会わせるか、全体をビデオに記録しなければならないと定めている。どのCAの鍵も複数の人間が共同で生成しなければならず、そのうちの誰一人として、単独で生成できるだけの知識をすべて持っていてはならない。

2025年4月30日、eMudhraは24の中間CAをまとめて作成した。それらはA、B、Cと名づけられた3つの系列に分かれ、鍵の種類はRSAと、P-384と呼ばれる楕円曲線型の2種類、用途は4種類だった。破られた8つの鍵は、B系列とC系列のP-384鍵のすべてだった。8つとも256より小さい整数だった。すべての桁を書き出すと、どれもゼロが長く並び、最後の1バイトにだけ何かが入っていた。

この鍵が推測できた理由

P-384曲線の秘密鍵は、単なる一つの数である。1から、それ自体が384ビットの長さを持つ一定の上限までの間で、ランダムに選ばれる。公開鍵は秘密鍵から計算で求められる。その計算は順方向にたどるのはたやすく、きちんとランダムな数であれば、逆にたどるのは絶望的だ。公開鍵は証明書に記載されている。4という数は秘密鍵としてまったく正当である。同時に、誰もが真っ先に試す数の一つでもある。Mozillaが指摘したとおり、これほど小さな鍵はほぼ瞬時に復元できる。1、2、3と順に256までの公開鍵を計算し、それぞれを証明書にある公開鍵と比べればよい。二つが一致したら、秘密鍵は計算を始めたその数である。きちんとランダムな鍵には、そんな短い候補リストは存在しない。スコット・ヘルムの言葉を借りれば、その範囲にはおよそ10の115乗通りの可能性があり、「だから、誰であれそれを探索することなど決してない」。Mozillaのデニス・ジャクソンは、ローカルで動くAIエージェントにもこの作業を任せた。エージェントは簡単なプロンプトから、最初の試みで鍵を復元した。

キーセレモニーから、なぜこれほど小さな数が生まれたのか。10月19日に投稿されたeMudhraの暫定的な説明によれば、その日に使ったスクリプトに欠陥があったという。同社の説明はこうである。鍵のエクスポートを試すため、通常の手順を一度だけ変更することを承認した。ところがコーディングの誤りによって、ハードウェアが正規の鍵ペアと並んで、より弱い2組目の鍵ペアを作成した。そしてラベルが似ていたために、誤ってその弱い鍵で証明書を申請してしまった。鍵は、CAの鍵を生成し守るための耐タンパー装置である、Utimaco製のハードウェアセキュリティモジュールで生成されたという。

eMudhra自身がこの説明を暫定的なものとしており、核心の謎は解けていない。Mozillaの公開バグ報告に書き込んだある人物は、鍵が安全なハードウェアの外で作られ、ポリシーに反してそこに読み込まれたのか、あるいはハードウェア自体が欠陥のある鍵を作るよう何らかの形で設定できたのか、そのどちらかだと指摘した。Mozillaの公開メーリングリストでは別の参加者が、ハードウェア内部の本物の鍵を指し示す小さなファイルを、ソフトウェアが鍵そのものと取り違えたのではないかと、確証のないまま推測した。Mozillaは、はるかに本腰を入れて試みても、同じバッチのA系列のP-384鍵は復元できなかった。Mozillaは10月20日、24時間の期限付きでeMudhraに質問を送ったが、10月23日の時点で回答は届いておらず、弱い鍵がどのようにして生まれたのかも説明されていなかった。

記録からはっきりしているのは、問題が1年以上前にすでに姿を見せていたことである。2025年6月、ある公開の監視サービスで、eMudhraがまさにこれらの中間CAについて、署名が無効な証明書失効リスト6件を配信していることが示された。失効リスト（CRL）とは、CAが取り消した証明書を記した署名付きの台帳であり、その署名はCAの証明書にある公開鍵で検証できなければならない。当時のeMudhraの報告によれば、別の証明書事業者であるSectigoが2025年6月3日に最初にメールで警告していたが、そのメッセージは社内のフィルターで隔離され、誰の目にも留まらなかった。問題のリストは6月6日に差し替えられた。

2026年10月、eMudhraはそのときの修正の中身を説明した。リストは当初、本来の、きちんとランダムな鍵で署名されていた。ところが証明書に入っていたのは弱い鍵の公開鍵のほうだったため、その署名は検証に失敗し、同社は欠陥のある鍵でリストに署名し直した。つまり2025年6月の時点で、eMudhraは自社の証明書が、使っているつもりの鍵と一致していないという証拠を手にしていた。そして同社は、リストを直した。

Chromeのルートプログラムは、eMudhraがなぜ業務を停止し、これらのCAに鍵ペアが2組存在する理由を調べ、証明書を失効させるのではなく、ただリストに署名し直しただけだったのかを尋ねた。eMudhraは、自社のルートと発行CAが2年続けて独立した監査を受けていたとしている。ウェインの報告の3日前にあたる2026年10月14日、同社は別のルート、emSign Root TLS CA – G1の失効リストを公開したが、その署名もやはり検証できなかった。

二種類のオフスイッチ

Chromeの最初の一手が速かったのは、鍵を標的にしたからである。ChromeはCRLSetと呼ばれるブロックリストを持っており、Googleはそれをバックグラウンドでブラウザーに配信している。UTC 19時45分に反映された更新は、6つの中間CAの公開鍵のフィンガープリントをブロックした。ブロックが鍵を名指ししていたため、偽造者が後から作るかもしれないものも含めて、それらの鍵を使うすべての証明書が対象になった。MozillaはFirefoxで独自のリストOneCRLを通じて証明書をブロックし、UTC 22時59分に完了した。OneCRLは、ユーザーがFirefoxを更新しなくても、再起動さえしなくても機能する。

バックグラウンドで配信されるリストは、それを受け取るソフトウェアしか守れない。Mozillaは10月20日、設定のせいでブロックリストが届いていなかったユーザー向けにFirefoxのアップデートを公開し、のちに、それを適用していなかった一部のFirefox for Androidのプロファイル向けの修正も出した。Googleは10月19日月曜日のUTC 22時ごろから、Google Play開発者サービスを通じて同等のブロックをAndroid端末に送り始め、翌日には大半の端末に届いたと述べた。MicrosoftとAppleも数日のうちに続いたが、Appleが対応した正確な日付については、公表された記録の間で食い違いがある。

認証局も動いた。eMudhraは10月18日UTC 9時38分までに8つの証明書すべてを失効済みとし、失効理由をCAの危殆化とした。中間CAにクロス署名していたSectigoは、10月19日にクロス証明書の失効を完了した。Chromeはさらに、危殆化したCAにチェーンするあらゆる証明書をCertificate Transparencyのログが拒否するよう手配した。これで偽造証明書は、CTを確認するソフトウェアが要求するログの記録を得られなくなった。

より重い手段は、中間CAに権限を与えたルートそのものを取り除くことだ。10月20日、すでに複数の人が独自に鍵を復元していることを踏まえて、Mozillaは、破られた中間CAの上位にあるeMudhraのルート、emSign ECC Root CA – G3を、自らのルートストアから緊急に削除することを決めた。Firefoxにその削除は必要なかった。FirefoxはすでにOneCRLで守られていたからだ。削除は、OneCRLを使わずに、Mozillaのルートリストやそこから派生したリストを使うほかのすべての人々のためのものだった。Mozillaは、サーバーが新しい証明書チェーンに移行するまで、この変更によってそうした利用者が一部のサーバーに接続できなくなると警告した。

Chromeも同じルートを自らのストアから削除した。Googleは、この変更がChrome Root Storeに依拠するすべての端末に届くのは太平洋時間の2026年10月27日火曜日の朝で、テスト版のCanaryとBetaにはそれより早く届くと見込んでいた。Googleは、その結果、このルートにチェーンする正規の証明書の一部がChromeで機能しなくなると率直に述べた。

二つのスイッチは、何を捕らえ、誰を傷つけるかが異なる。ルートの削除は、誠実なウェブサイトのものも含めて、そのルートを通るあらゆる経路を断つが、ほかのルートを通る経路は見逃す。そしてeMudhraの中間CAには、別の経路があった。Sectigoがそれらにクロス署名し、同じ鍵を、Comodoの名で発行されたAAA Certificate Servicesというルートに結びつけていたのである。Chromeは2025年4月にこのルートを除外していたが、まだ信頼しているシステムもあった。UbuntuはサポートしているすべてのリリースからemSign ECC Root CA – G3を削除し、Comodoのルートをまだ収録していた古いリリースからは、そちらも削除した。中間CAそのものを対象にしたブロックなら、あらゆる経路を一度に捕らえられる。プログラミング言語のGoはこの方法を取った。10月19日に公開されたバージョン以降、Goの証明書検証機能は、どのルートで終わるかにかかわらず、危殆化した中間CAのいずれかを含むチェーンを除外する。

ほかのすべての人々の更新

10月18日、Mozillaは公開バグ報告に、より広いエコシステムが心配だと書いた。多くのエンドポイントには、失効情報を受け取る実効的な手段がないからである。ブラウザーには、バックグラウンドで配信されるリストがあった。安全な接続を行うそれ以外の多くのソフトウェアには、それに類するものが何もない。

Mozillaのデニス・ジャクソンが立ち上げた公開ページであるインシデント追跡サイトは、誰が危険にさらされているのかを具体的に示した。信頼されたルートの独自のバンドルを同梱するアプリケーションやライブラリには、ソフトウェアの更新が必要だった。Electronで作られたアプリも同じである。ElectronはSlackやDiscordといったデスクトップ・プログラムの基盤となるフレームワークで、こうしたアプリは修正済みのリリースで再ビルドされて初めて、Electronの修正を取り込む。

隙間の一部は、オペレーティングシステム自身の信頼ファイルにあった。インシデント追跡サイトによれば、10月22日時点でmacOSは危殆化した中間CAをブロックしていたが、curl、git、python3をはじめとする組み込みのコマンドラインツールは、失効情報を参照せずに別のファイルで証明書を検証しており、そのファイルは更新されていなかった。Ubuntuでは、10月22日の時点でCanonicalが解決していなかった同期の問題のため、システムの更新後もJavaのルートストアに手作業での対応が必要だった。snapパッケージとしてインストールされたブラウザーは、そもそもシステムのストアを使っていなかった。

ほかの隙間は、独自のリストを持つライブラリにあった。Goは修正をセキュリティリリース1.27.3と1.26.10として、CVE-2026-111943のもとで公開した。広く使われているPythonのcertifiバンドルは、10月18日にemSignのルート4つをすべて削除し、その後、影響を受けていない3つを2026.10.19というタグのリリースで復元した。10月23日の自動リリースでは、その3つのうち2つが再び外された。さらに、メーカーにしか直せない製品もあった。CiscoのセキュリティチームTalosは、更新が必要になりそうなものとして、とくに仮想プライベートネットワークを挙げた。

これらすべての根底にあったのが、Certificate Transparencyである。ほとんどのブラウザーはこれを強制するが、curlをはじめ、ブラウザー以外の多くのクライアントは強制しない。eMudhraの鍵の一つで作られ、一度もログに記録されなかった偽造証明書は、Chromeには拒否されるが、そうしたクライアントには受け入れられる可能性があった。それらのクライアントがまだeMudhraのチェーンを信頼しており、ほかに止めるもの、たとえば自社サーバーの既知の証明書しか受け入れないアプリのような仕組みがなければ、の話である。

システムは機能した、と言える強い根拠がある。10月17日のChromeによるブロックより前に、6つの中間CAにチェーンするウェブサイト証明書がCertificate Transparencyに記録されたことは一度もなかった。したがって、2025年4月の鍵の作成からそのブロックまでの間、これらの鍵による偽造証明書が、CTを強制するクライアントに対して使われることはあり得なかった。Talosは、10月21日UTC 14時の時点で、実環境での悪用は確認していないと述べた。eMudhraによれば、影響を受けた中間CAのうち本番運用に入ったのは1つだけで、ウェブサイトやソフトウェアメーカーに証明書を発行したものは1つもなかった。

終始CTを強制していたソフトウェアについては、この主張は正しい。そしてその守りは、週末の緊急対応ではなく、常設のルールから来ていた。ただし、それが及ぶ範囲は、「システムは機能した」という言い方が思わせるよりも狭い。Firefox for AndroidがCertificate Transparencyの強制を始めたのは、2025年11月11日にユーザーへ初めて提供されたバージョン145からにすぎない。Androidアプリが組み込みのCTチェックを使えるのはAndroid 16以降で、それが標準で有効になるのは、Android 17向けにビルドされた場合に限られる。

緊急対応は、その後に起きたことにとっても重要だった。Mozillaがルートストアの下流のメンテナーに最初に送った通知は、鍵が誰にでも復元できることを意図的に伏せていた。10月20日には、それもほとんど意味を失っていた。複数の人が独自に鍵を復元し、ヘルムがその値を8つすべて公表していたからだ。鍵が事実上公開された以上、鍵と新たな偽造との間に立ちはだかっていたのは、ブロックとCTログによる拒否だった。10月24日までに公表された情報からは、2025年4月から2026年10月までの間に、攻撃者がCTを強制しないクライアントに対して欠陥のある鍵を使ったかどうかはわからなかった。

スイッチを握るのは誰か

ブラウザーやオペレーティングシステムがどのルートを信頼するかを決めるのはルートプログラムであり、その規則は運営者に広い裁量を与えている。Chromeのポリシーは、Googleが「独自の裁量で」証明書を収録または削除すると定め、収録される証明書はいずれも、それを残しておくリスクを上回る価値をユーザーにもたらさなければならないとしている。Mozillaのポリシーは、独自の裁量で、いつでも、いかなる理由でも証明書を無効化または削除できるとしている。Mozillaはまた、収録に料金は一切取らないとしている。

その裁量は、さまざまな形で行使されてきた。2014年、インドの国立情報学センターがGoogleの複数のドメインに対して無許可の証明書を発行したとき、Chromeはその上位にあるインドCCAのルートを放り出しはしなかった。そのルートを、インドのドメインの一覧に限定したのである。その3年前、オランダの認証局への対応は全面的なものだった。2011年9月3日、GoogleはDigiNotarが運営するすべての認証局を拒否することを決め、その17日後、オランダの裁判所が同社の破産を宣告した。

DigiNotar、2011年

DigiNotarの侵害が明るみに出たのは、一人のごく普通のユーザーを通じてだった。2011年8月28日、イランのインターネット・プロバイダーParsOnlineの利用者が、Chromeに表示された証明書の警告について、Googleのサポートフォーラムに投稿した。その証明書はGoogleのものだと称しており、システムに侵入されていたDigiNotarから発行されたものだった。オランダ政府の依頼で調査にあたったセキュリティ企業Fox-ITの調査員たちはのちに、google.comのアドレスを対象とする不正な証明書が、約30万人のユーザーに対する大規模な攻撃に使われていたことを突き止めた。そのほぼ全員がイランにおり、Googleとの通信はおそらく傍受されるか、リダイレクトされていた。調査員たちはこの推計を、偽造証明書の状態を確認した29万8140の異なるインターネットアドレスから導き出し、きわめて大まかな概算だとしている。9月3日、オランダ政府はDigiNotarへの信頼を公に撤回した。2026年10月下旬の時点で、eMudhraの鍵を使った攻撃は報告されていない。DigiNotarが示したのは、CAの署名の力が、それを使う意思のある者の手に渡ったとき何をもたらすかである。

Googleによれば、Chromeのルートストアに収録されるには、CAの所有者が、Chromeのユーザーを守るのに必要な技術的能力と運用の厳格さを継続的に示さなければならない。そしてGoogleは、eMudhraの残りのCA証明書を引き続き収録すべきかどうかを「綿密に調査している」と述べた。10月23日、eMudhraは公開バグ報告で、ソーシャルメディア上の激しい監視と、投資家や顧客による分析のために、この事象を意味のある形で分析することは「ほぼ不可能」になったと述べた。Chromeは同じ日、それは言い訳にならないと返した。eMudhraは、この仕組みに頼り、同社の過ちによって危険にさらされた「数十億」の人々に対して、なお義務を負っているというのである。

eMudhraの取締役会は、すでに10月22日に、世界向けのSSL/TLS証明書事業から撤退することを決めていた。同社によれば、この事業は事業全体のごく一部にすぎない。

同じ企業群は、CA/Browser Forumという組織で、CAとともに共通の規則も書いている。eMudhraが欠陥のある鍵を生成する19日前、2025年4月11日に締め切られた投票で、Apple、Google、Microsoft、Mozillaはそろってウェブサイト証明書の寿命を短くすることに賛成し、eMudhraを含む25の証明書発行者も賛成票を投じた。投票案の論拠は、インターネットの規模では失効は人々を十分に守れないが、有効期限切れなら守れる、というものだった。「証明書の有効期間と、依拠当事者によるその強制は、驚くほど信頼できる」と投票案は述べている。2026年10月時点で有効な規則では、2026年3月15日以降に発行されるウェブサイト証明書の有効期間は最長200日、2027年3月15日以降は100日、2029年3月15日以降は47日となる。

これらの上限は、ウェブサイトが使う証明書に、発行日を基準として適用される。規則の条文は、今回の事件の中心にあるCA証明書には上限を設けていない。したがって、有効期間を短くしても、eMudhraの中間CAが期限切れになることはなかった。失効がなくなったわけでもない。無料の認証局Let’s Encryptは2025年8月、ブラウザーが証明書を1枚ずつ問い合わせられるOCSPサービスを終了した。問い合わせのたびに、どのインターネットアドレスからどのサイトが閲覧されているかがCAに伝わってしまうからである。10月17日の緊急ブロックは、実質的には、ブラウザーメーカーが自ら選別して配信した失効リストだった。

この仕組みは、少数の民間の手、それも大半がアメリカ企業の手に、大きな力を委ねている。eMudhraの事例が示すのは、その力がどのように行使されるかである。誰もが質問と期限と回答を読める公開のバグ報告の場で、削除する側の企業が理由を公表しながら、それは行使される。

移行を迫られる証明書

ルートの削除は、発表するのはすぐでも、吸収するには時間がかかる。10月21日時点で、ChromeはemSign ECC Root CA – G3にチェーンする有効期限内のプレ証明書を約3万800件数えていた。プレ証明書とは、発行前に透明性ログへ提出される証明書の写しである。つまりこの数字はログに記録された証明書の数であって、それをまだ使っているウェブサイトの数ではない。そのうち3万791件、99.9%は、米国のネットワーク組織Internet2が運営する証明書サービスInCommonの、2つの中間CAから発行されたものだった。この2つは、破られた8つの中間CAには含まれていない。削除されるルートの下にぶら下がっていただけである。eMudhraは、移行が必要な証明書は約3万件で、そのほぼすべてが、サーバーが証明書を自動で申請・更新できるようにするプロトコルACMEを通じて発行されたものだと見積もった。eMudhraは10月20日、G3ルートのもとでの発行を停止した。

自動化だけで、これが片づくわけではない。標準的なACMEクライアントが証明書を差し替えるのは、更新日が巡ってきたときだけである。CAが早期の更新を求められる新しい拡張機能にクライアントが対応しているか、誰かが手作業で介入すれば話は別だ。Chromeは10月21日、eMudhraの楕円曲線の階層からRSAの階層に移るには、クライアントの設定を変える必要もありうると指摘した。

InCommonの証明書は、eMudhraを親会社とする供給元、CertiNextを通じて提供されている。10月22日、InCommonは加入者に向けて、春から夏にかけての、うまくいったものの消耗の大きい移行を終えたあとで、多くの加入者がこの1週間、証明書エラーへの対応と、自分たちには制御できない変更を見越した計画づくりに追われたと伝えた。その朝の助言は、楕円曲線の証明書の発行が再開されるまで、影響を受けた証明書をRSAで再発行するというものだった。

eMudhraは10月20日、G3の顧客にとって唯一の代替手段は、同社のRSAルートemSign Root CA – G1にチェーンする中間CAだと述べていた。Mozillaは同日、現時点ではG1への信頼を取り消さないと述べた。G1は、Chromeが10月20日に綿密に調査していると述べたeMudhraの残りの証明書に含まれており、10月24日時点で、Chromeは決定を発表していなかった。10月21日、ChromeはeMudhraに対し、顧客をG1に移すのか、他社の階層に移すのか、あるいはその両方なのかを確認するよう求めた。

10月22日夜のInCommonの更新は、目前の問題を片づけた。楕円曲線の証明書は、今度はG1ルートにチェーンする形で再び発行されるようになり、既存のクライアントは設定を何も変えずに更新できた。同じ更新は、eMudhraが30日後、CertiNextが確定する日に、公開ルートにチェーンするすべての中間CAからの発行を停止すること、そしてInCommonが代わりの発行経路を整えようとしていることを伝えていた。春から夏にかけて骨の折れる移行を一度終えたばかりの加入者たちにとって、ルートがひとつ削除されたことは、次の移行の始まりを意味した。

関連記事

• 米国の制裁リストはハーグの裁判所にどこまで届くのか
• ビットコインはこれからどうなるのか
• AIは実際にどう動いているのか:見出しが伝えない、開発者たちの知っていること

参考図書

Amazonのアソシエイトとして、Eikleafは適格販売により収入を得ています。以下の書籍リンクはアフィリエイトリンクです。リンク経由でご購入いただくと、追加費用なしで当サイトに少額の手数料が支払われる場合があります。

おすすめ動画

生成AIに関する免責事項

このページの内容の一部は、生成AIの支援を受けて作成および／または編集されています。

メディア

ウェブサイトのアドレスバーのHTTPSと鍵アイコン – Wikimedia Commons (写真：Santeri Viinamäki, CC BY-SA 4.0)

nCipher nShield F3ハードウェアセキュリティモジュール – Wikimedia Commons (写真：Alexander Klink, CC BY 3.0)

Googleplex本社 – Wikimedia Commons (写真：Asoundd, CC BY-SA 4.0)

主な出典と参考文献

Mozilla Bugzilla. “Bug 2083449: eMudhra: Private key compromise of Intermediate Certificates.” Opened 18 October 2026, comments to 23 October 2026. https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

Chrome and Android Security Teams. “Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates.” Google, The Keyword, 20 October 2026. https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/

Mozilla dev-security-policy mailing list. “Compromised eMudhra Intermediate Certificates” thread, posts by Dennis Jackson (Mozilla) and the Chrome Root Program, 20 October 2026, and by Wayne and Corey Bonnell, 21 October 2026. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE

Jackson, Dennis. “eMudhra Intermediate CA Compromise.” Incident tracking site, 20 October 2026, updated 22 October 2026. https://emudhra.we-have-a-problem.com/

InCommon (Internet2). “Moving Forward Together: InCommon Certificate Service Update.” Updates of 22 October 2026. https://incommon.org/about/news/incommon-certificate-service-update

InCommon (Internet2). “InCommon Certificate Service FAQ.” Last updated 22 October 2026, 18:30 ET. https://incommon.org/certificates

Stanescu, Luci. “eMudhra CA compromise fixes available.” Ubuntu blog, Canonical, 20 October 2026, updated 22 October 2026. https://ubuntu.com/blog/emudhra-ca-compromise-fixes-available

Canonical. “USN-8944-1: ca-certificates update” and “USN-8944-2: ca-certificates update.” Ubuntu security notices, 20 October 2026. https://ubuntu.com/security/notices/USN-8944-1 and https://ubuntu.com/security/notices/USN-8944-2

Go team. “[security] Go 1.27.3 and Go 1.26.10 are released.” golang-announce, posted 20 October 2026 (releases dated 19 October 2026). https://groups.google.com/g/golang-announce/c/66pojueaQek

Go project. “Release History.” Accessed 24 October 2026. https://go.dev/doc/devel/release

certifi. “Remove emsign (#437),” “Restore unaffected emSign roots (#439) (#440)” and “2026.10.23 (#445).” python-certifi repository, 18, 20 and 23 October 2026. https://github.com/certifi/python-certifi/commit/5cb238caeeb6c30ec1a7309ad3e16a5aa7b10ce8 and https://github.com/certifi/python-certifi/commit/662df63d7906df66f1f07c0751a3dfe9da14d914 and https://github.com/certifi/python-certifi/commit/b60466c9f2882d9cf088943c650b0faac06c080c

Cisco Talos. “Compromised eMudhra intermediate certificates.” Talos Intelligence blog, 21 October 2026. https://blog.talosintelligence.com/compromised-intermediate-certificates/

eMudhra Limited. “eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA.” 21 October 2026. https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca

eMudhra Limited. “eMudhra to exit global SSL/TLS certificate business.” 22 October 2026. https://emudhra.com/en/press-release/emudhra-to-exit-global-ssl-tls-certificate-business

Abrams, Lawrence. “Mozilla, Google, Apple block compromised eMudhra CA certificates.” BleepingComputer, 20 October 2026. https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/

Helme, Scott. “Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds.” 20 October 2026. https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/

Sharwood, Simon. “Indian certification authority eMudhra’s private keys compromised – one of them was the number ‘4’.” The Register, 20 October 2026. https://www.theregister.com/a/5304312

Mozilla Bugzilla. “Bug 1970728: eMudhra: Invalid CRL signatures.” June 2025. https://bugzilla.mozilla.org/show_bug.cgi?id=1970728

Mozilla. “Firefox for Android 145.0 release notes.” 11 November 2025. https://www.firefox.com/en-US/firefox/android/145.0/releasenotes/

Cooper, D., et al. “RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.” IETF, May 2008. https://www.rfc-editor.org/rfc/rfc5280

Laurie, B., Langley, A., and Kasper, E. “RFC 6962: Certificate Transparency.” IETF, June 2013. https://www.rfc-editor.org/rfc/rfc6962

CA/Browser Forum. “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.3.1.” 4 October 2026, sections 3.2.2.4.7, 6.1.1.1 and 6.3.2. https://github.com/cabforum/servercert/blob/3574ae809e5f909b58ee4c26b7bac4a3b9e78421/docs/BR.md

CA/Browser Forum. “Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods.” 11 April 2025. https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

Google. “Chrome Root Program Policy, Version 1.8.” Last updated 5 February 2026. https://googlechrome.github.io/chromerootprogram/crp/policy/

Mozilla. “Mozilla Root Store Policy, Version 3.1.” Effective 1 July 2026. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Aas, Josh. “OCSP Service Has Reached End of Life.” Let’s Encrypt, 6 August 2025. https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life/

Adrian, David, Serena Chen, Joe DeBlasio, Emily Stark and Emanuel von Zezschwitz. “An update on the lock icon.” Chromium Blog, May 2023. https://blog.chromium.org/2023/05/an-update-on-lock-icon.html

von Zezschwitz, Emanuel, Emily Margarete Stark and Serena Chen. “‘It builds trust with the customers’ – Exploring User Perceptions of the Padlock Icon in Browser UI.” SecWeb 2022, IEEE. https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/

Android Developers. “Network security configuration: Certificate transparency.” Accessed 24 October 2026. https://developer.android.com/privacy-and-security/security-config

Langley, Adam. “Maintaining digital certificate security.” Google Online Security Blog, July 2014. https://security.googleblog.com/2014/07/maintaining-digital-certificate-security.html

Adkins, Heather. “An update on attempted man-in-the-middle attacks.” Google Online Security Blog, 29 August 2011, updated 3 September 2011. https://security.googleblog.com/2011/08/update-on-attempted-man-in-middle.html

Fox-IT. “Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach.” 13 August 2012. https://zoek.officielebekendmakingen.nl/blg-191225.pdf