eMudhra中間CAの鍵復元問題に伴う多層的な不信化と、トラストストア・ランタイムの検証実務

eMudhraのGlobal TLS事業における中間CA鍵復元問題（CVE-2026-111943）では、eMudhraは開示前に対象の8つの中間CAから自社が顧客向けエンドエンティティ証明書を発行していないと説明しています。開示後には第三者が6鍵で署名した107,107件がCTログに記録され、うち106,050件はPoCです。AWS環境では、AWS管理TLSトラストバンドルから「AAA Certificate Services」「emSign Root TLS CA – G3」「emSign ECC Root CA – G3」の3ルート証明書が削除されます。これにより、該当ルートに連鎖する証明書を利用するCloudFrontのオリジンサーバーや、ALBのOIDC/JWT認証で利用するIdP（2026年10月28日までに証明書差し替えが必要）などが影響を受けます。更新の要否は、利用中の証明書チェーンを展開して上記3ルートへの到達有無を確認するとともに、各システムやランタイムが参照する信頼ストアの更新状況および失効検証方針を照合して判断します。

何が起きたか：eMudhra中間CAにおける乱数不足と鍵復元の仕組み

公開鍵暗号基盤（PKI）において認証局（CA）が署名に用いる秘密鍵の健全性は、Web全体の通信セキュリティを担保する大前提です。2026年10月、eMudhraのGlobal TLS事業で発行された中間CA証明書に対応する秘密鍵が、外部から容易に復元可能となる問題が公表されました。本件はCVE-2026-111943として登録されており、CNA（CVE Numbering Authority）を務めたGo Projectによって「crypto/x509における侵害された中間証明書の不信化」と題されています[1]。Goの修正告知では、影響を受ける中間証明書を含む証明書チェーンを検証結果から除外する旨が明記されており、AWSも公式セキュリティ告知において同一のCVE番号を掲げています[1, 2]。

問題の対象となったのは、eMudhraのGlobal TLS事業における8つの中間CAです[3]。eMudhraの発表によると、KGC（Key Generation Center）のwrap/unwrap段階で脆弱な鍵セットが生成されたと説明されています[3, 4]。同社は正確な根本原因については調査中としており、AWSの告知ではエントロピー不足、GoogleのChrome Root Programでは不十分な乱数による鍵の脆弱性と表現されています[3, 4]。eMudhraはKGCのwrap/unwrap段階で第二の弱い鍵セットが生じたと説明していますが、正確な根本原因や詳細な処理手順は調査中とされており、正確なAPI呼び出し手順や入力材料、セレモニー記録などを外部から独立して再構成することは困難とされています[5]。

補足：KGC（Key Generation Center）とは

公開鍵暗号基盤において、暗号鍵の生成や管理を集約して実施するシステムコンポーネントです。

楕円曲線暗号（ECDSA）における鍵生成の仕様上、秘密スカラー $d$ は暗号論的擬似乱数生成器（DRBG）から規定範囲 $[1, n-1]$ でランダムに選択され、公開鍵 $Q$ はベースポイント $G$ に対するスカラー倍算 $Q = [d]G$ として算出されます[6]。候補となる秘密スカラーの範囲が極端に狭く列挙できる場合や、乱数生成器の出力を予測できる場合には、公開鍵から秘密鍵を現実的な計算時間で復元できることがあります[6]。Mozillaが公開した独立調査の報告によると、影響を受けた8つの中間CA（TLS用6件、コード署名用2件）のP-384秘密鍵はすべて秘密スカラー $d$ が256未満の整数値として容易に回復されており、のちに概念実証で署名に使われたのはこのうちTLS用の6鍵で、未回復とされたA/A-1系列のP-384鍵や未調査のRSA鍵は別の中間CA群を指します[7]。公開鍵 $Q$ に対して小さな候補スカラーを順次照合する計算により、秘密鍵が直接特定可能な状態にありました[8]。

同時期にNode.jsなどのセキュリティ告知において、本インシデントに伴うCA証明書の更新と、圧縮ライブラリBrotliの脆弱性（CVE-2026-111497）への対応が併記されました[9]。しかし両者は異なる技術レイヤーの事象です。Brotliの問題は不正な圧縮入力によるデコーダーのバッファ範囲外書き込みというメモリ安全性の欠陥に対処するものであり、eMudhraの問題はPKIにおける署名鍵の強度と信頼経路の破綻に対処するものです[9]。詳細なデコーダーの波及構造については、関連記事「Google Brotli脆弱性（CVE-2026-111497）の波及と、同梱デコーダーの実体特定に基づく更新・再配備」を参照してください。

なぜ今対処が進んだか：発見から一斉失効・事業撤退までの経緯と観測事実

インシデントの端緒となったのは、2026年10月17日16

UTCに行われたCCADB（Common CA Database）の証明書群に対する検査でした[10]。検査において楕円曲線暗号鍵の異常が発見され、同日18 UTCには主要なルートプログラムおよびeMudhraに対して証拠を添えた報告が送信されました[10]。Mozillaは翌10月18日12 UTCに、メール連絡の混線を防止する目的でBugzillaに起票しました[10]。

報告を受けた主要ベンダーは迅速な遮断措置に踏み切りました。Google Chromeは10月17日19

UTCにCRLSetを更新して影響を受ける中間CAを遮断し、CRLSetの更新を受信しない環境に向けて署名元である「emSign ECC Root CA - G3」をChrome Root Storeから削除する措置を講じ、全端末への展開を10月27日に予定しました[11]。Mozilla Firefoxは同日22 UTCまでに標準設定の全ユーザーに対するOneCRLの配布を完了し、10月20日にはFirefoxのアップデートおよびNSS 3.131.1をリリースして、カスタム設定のユーザーやNSSを利用する外部アプリケーションへ対処を拡大しました[11]。

認証局側では、eMudhraが10月18日に対象の中間CA 8件を失効させました[12, 13]。翌10月19日にはSectigoがこれら中間CAに対するクロス署名証明書を失効させました[12]。さらにソフトウェア環境では、Go Projectが10月19日にGo 1.27.3および1.26.10をリリースし、crypto/x509パッケージに対象中間CAのdenylistを追加して検証チェーンから除外する修正を導入しました[14]。Pythonなどで利用される証明書バンドルCertifiは、10月18日にすべてのemSignルート証明書を一時的に一括削除した後、10月19日のリリースで影響のないルート証明書を復元しました[14]。eMudhraのインシデント説明ページは初掲載日を10月20日としており、根本原因の全容は調査完了後に公表するとしていますが、10月20日を初公表日とした具体的な理由は説明されていません[15]。

2026年10月22日、eMudhraはGlobal SSL/TLS証明書事業からの自主撤退を発表しました[16]。SNS上での反響による注目が自社の事業規模に対して過大になったことを理由に挙げており、顧客の移行完了まではG1 RSAルートを維持しつつ、パートナー経由で無償の証明書交換を実施する方針を明らかにしています[16]。

補足：CRLSetおよびOneCRLとは

ブラウザーベンダー（Google ChromeやMozilla Firefox）が、失効した中間CA証明書やエンドエンティティ証明書の情報を集約し、独自の更新チャネルを通じてブラウザーへプッシュ配信する高速な失効リスト配信機構です。

一連の対応タイムラインを整理すると以下のようになります。

本インシデントにおける悪用の有無については、客観的な観測事実と技術的な限界を区別して評価する必要があります。eMudhraは、対象となった8つの中間CAから発行されたエンドエンティティ証明書は0件であり、開示前に脆弱な鍵が回収または悪用された証拠は把握していないと申告しています[17, 21]。またGoogleは、初回ブロック前の確認において、対象のTLS中間CA 6件につながる証明書はCT（Certificate Transparency）ログ上に0件であったと報告しています[18, 19]。ただしこの確認結果は、CTログへの登録を強制しているChromeの既定動作やCT enforcementを持つブラウザーの観測範囲に限られた評価です[18, 19, 20]。

Mozillaの公開Bugzilla記録によると、脆弱性の開示後に対象の6鍵を用いて署名された証明書107,107件がCTログに記録され、そのうち106,050件がgoogle.comを対象とする概念実証（PoC）証明書であったことが確認されています[22]。これは鍵の復元可能性と署名可能性を実証するデータですが、開示前における悪意ある第三者による不正発行や中間者攻撃の成功を示すものではありません[22]。加えてMozillaの調査では、A/A-1系列のP-384鍵は回復されておらず、RSA鍵についても未調査とされています[23]。したがって、確認された鍵の回復結果のみをもって、同じ鍵生成セレモニーの全鍵や別の中間CAが安全であると結論づけることはできないと評価されています[23]。

何が変わるか：証明書失効とトラストストア・ランタイムの多層防御

中間CAの鍵侵害が発生した際、影響を最小化するために複数の防御レイヤーが連動します。証明書の失効確認手段としては、RFC 5280に規定されるCRL（Certificate Revocation List）と、RFC 6960に規定されるOCSP（Online Certificate Status Protocol）が存在します。CRLは発行CAが署名する失効証明書のシリアル番号リストであり、クライアントが最新のリストを取得して照合を行いますが、失効が反映されるタイミングはCRL自体の発行・更新周期に制約されます[24]。一方のOCSPは証明書の現在の状態（good、revoked、unknown）をオンラインで照会するプロトコルですが、検証を行うにはステータスサービスへのネットワーク接続が必要であり、ステータスがunknownの場合や接続不能時における代替照会・拒否方針はクライアント側に委ねられます[25]。

トラストストアの更新は、信頼するルートCAの集合そのものを変更する措置です。Amazon Linuxのca-certificatesパッケージから対象ルート証明書を削除すると、そのルートに連鎖するすべての証明書チェーンが、システム全体の証明書ストアを参照するアプリケーションから信頼されなくなります[26, 27]。さらに、Go言語のcrypto/x509パッケージでは、OSの証明書ストアとは独立して、検証ロジック内に侵害中間CAのdenylistを組み込みました[27, 28, 29]。これにより、OS側のトラストストア更新が適用されない環境であっても、ランタイムレベルで侵害チェーンを直接排除する多層防御が成立します[27, 28, 29]。

補足：EKU（Extended Key Usage）とは

X.509証明書の拡張領域に定義される属性で、TLSサーバー認証、コード署名、クライアント認証など、その公開鍵が利用可能な暗号プロトコルの用途を制約する識別子です。

中間CAの影響範囲は、証明書に付与されたEKU（Extended Key Usage）属性によっても分かれます。Chrome Root Programの対応では、対象となった8つの中間CAのうちTLS用途の6件が即時ブロックの対象とされました[30]。残る2件のコード署名用中間CAについては、EKU制約によりTLS接続の検証経路を構成できないため、TLS遮断の対象に含める必要がなかったと説明されています[30]。

証明書失効と信頼ストア・ランタイムによる各防御手法の特性を比較すると、下表の通り整理できます。

防御レイヤー・方式	主な動作仕様	反映の即時性と更新タイミング	クライアント実装上の制約・留意点
CRL（RFC 5280）	発行CAが署名した失効シリアル番号一覧を照合[24]	CRL発行周期に依存し、次回更新まで反映にタイムラグが生じる[24]	クライアント側での定期取得とキャッシュ管理が必要[24]
OCSP（RFC 6960）	レスポンダーへ証明書の現在状態をリアルタイム照会[25]	応答の有効期間内で最新状態を反映[25]	ステータスサーバーへの接続が必要。接続不能時の動作はクライアント設定に依存[25]
トラストストア更新（OS/証明書バンドル）	信頼するルートCA集合から対象証明書を削除[26, 27]	パッケージ更新やOSの再起動・プロセス再起動時に反映[26]	依存するすべてのエンドエンティティ証明書の検証が一括で失敗する[26]
ランタイム層denylist（Go crypto/x509等）	ライブラリ内の検証ロジックで侵害中間CAを直接除外[28, 29]	アプリケーションの再ビルドまたはランタイム更新時に即時反映[28]	OSトラストストアの更新が届かない環境でも個別に対処可能[28, 29]

実務上重要な論点となるのが、クライアント側の失効検証方針です。AWSは公式告知において、OCSPまたはCRLを「fail-closed」（失効確認に失敗した場合は接続を拒否する設定）で検査するクライアントを影響対象外としています[31, 32, 33]。一方で、Mozillaは通信を傍受できる攻撃者が偽装証明書を用いてウェブサイトになりすますリスクを指摘しており、Googleも対象CAへの信頼を解除していないクライアントに対して偽造証明書が成立し得ると述べています[31, 32, 33, 34]。これら複数の公式発表を総合すると、失効確認を省略しているクライアントや、確認失敗時にも通信を許可する「soft-fail」設定のクライアントでは、不信化情報がトラストストアやランタイムに反映されるまでの間、通信傍受環境下で中間者攻撃（MITM）を受けるリスクが残存するという推論が成り立ちます[31, 32, 33, 34]。したがって運用者は、単にOSのCAパッケージを更新するだけでなく、各アプリケーションやランタイムがどの信頼ストアを参照し、どのような検証経路と失効ポリシーを持っているかを個別に確認する必要があると評価されています[35]。

誰に影響するか：AWS環境における影響対象と非対象、対応スケジュール

AWS環境における影響を把握する上では、「AWS管理TLSトラストバンドル」の役割を理解することが重要です。AWSの定義によると、このトラストバンドルは、AWS各種サービスがIdP（アイデンティティプロバイダー）、オリジンサーバー、Webhookエンドポイントなど、ユーザーが設定した外部の宛先へのアウトバウンドTLS接続を検証するために使用する証明書ストアです[36]。

AWSはこのトラストバンドルから影響対象として削除するルート証明書として、以下の3件を列挙しています[37, 38, 49]。

• AAA Certificate Services
• emSign Root TLS CA – G3
• emSign ECC Root CA – G3

eMudhraは中間CA証明書を失効させ、ルート証明書は失効させていないと説明していますが、ブラウザーのroot programは予防的措置としてECCルート証明書1件を不信化しました[39, 40]。また、eMudhraのインド国内におけるDSC（Digital Signature Certificate）やeSign事業はGlobal TLS事業とは別個のインフラで運用されており、本インシデントの対象外とされています[41]。

補足：AWS管理TLSトラストバンドルとは

AWSサービスが、外部のIdP、オリジンサーバー、Webhookエンドポイントなど、ユーザーが設定した外部宛先へアウトバウンドTLS接続を行う際に、接続先の正当性を検証するために参照する事前定義済みの証明書ストアです。

トラストバンドルから上記3ルートが削除されることにより、これらに連鎖する証明書を利用している構成では影響が生じます。AWSは、CloudFrontのedge CA bundleから対象ルートが削除された後、該当ルートに連鎖するオリジンサーバーへのTLS検証が失敗する可能性があると案内しています[37, 42, 43]。また、Application Load Balancer（ALB）においてOIDC/JWT認証機能を利用し、認証先IdPの証明書チェーンが対象ルートに連鎖している場合、AWSが信頼するCAが発行した証明書へ2026年10月28日までに差し替えるよう求めています[37, 42, 43]。

AWSが公表した各サービスの更新スケジュールおよび利用者側で更新が必要なコンポーネントは以下の通りです[44, 45, 46, 47]。

対象分類	対象項目・コンポーネント	対応状態・反映目標日	運用者側の影響と確認事項
影響対象ルート証明書	AAA Certificate Services emSign Root TLS CA – G3 emSign ECC Root CA – G3[37, 38]	削除対象（AWS管理TLSトラストバンドル）[36]	当該ルートに連鎖するサーバー証明書・IdP証明書が検証失敗の対象[37, 42]
AWSインフラ・サービス	共有TLSトラストストア、STS、Cognito[44, 45]	2026年10月21日反映済み[45, 46]	アウトバウンドTLS接続における対象ルートの信頼を遮断[36]
AWSインフラ・サービス	CloudFront[44, 45]	2026年10月28日目標[45, 46]	オリジンサーバーの証明書チェーンが対象ルートに連鎖する場合、検証失敗[42]
AWSインフラ・サービス	ALB（OIDC/JWT検証用IdP）[44, 45]	既存: 10月29日〜31日目標 新規: 11月2日目標[45, 46]	該当チェーンを利用している場合、2026年10月28日までに証明書の差し替えが必要[43]
AWSインフラ・サービス	RDS for SQL Server / EMR[44, 45]	RDS: 10月30日目標 EMR: 10月31日目標[45, 46]	外部エンドポイントへのTLS接続検証におけるルート削除[44, 45]
利用者側パッケージ	Amazon Linux 2 / 2023（ca-certificates）[44, 45]	2026年10月24日提供済み[45, 47]	パッケージ更新によりシステム全体のトラストストアから対象ルートを削除[47]
利用者側ランタイム・SDK	Amazon Corretto[44, 45]	2026年10月24日提供済み[45, 47]	修正済みバージョンへの更新[47]
利用者側ランタイム・SDK	botocore（Python SDK）[44, 45]	1.43.117以降（PyPI公開済み）[45, 47]	バージョン1.43.117以降への更新[47]
利用者側OSイメージ	Bottlerocket（EKS/ECS）[44, 45]	AMI更新: 10月26日目標 商用パラメータ: 10月28日目標[45, 46]	v1.67.0以下のAMIを利用している場合、更新AMIへの差し替えが必要[45]

AWSの公表資料では、共有トラストストアの更新が10月21日に反映され、Security Bulletin自体の公表は10月24日付となっています[46, 48]。この間隔が生じた背景や、サービスごとに展開目標日が分かれている具体的な理由については、公式資料において説明されていません[48]。

実務における判断手順：証明書チェーンと信頼ストアの照合指針

自社システムが影響を受けるかどうかを判定する際、サーバー証明書の発行者名や中間CAの名前だけを見て判断することは避ける必要があります。重要なのは、エンドエンティティ証明書から中間CAを経て終端に至る完全な証明書チェーンを展開し、AWSが列挙した3つのルート証明書（AAA Certificate Services、emSign Root TLS CA – G3、emSign ECC Root CA – G3）のいずれかに到達していないかを確認することです[49, 51]。クロス署名が存在する場合、クライアントの信頼ストアによって解決されるルートが異なる場合があるため、チェーン全体をトレースして検証しなければなりません[49, 51]。

自社環境の各プロセスがどの信頼ストアを参照しているかの把握も求められます。OSのca-certificatesパッケージを参照するシステム、Java（Corretto）のように独自のkeystoreを保持している環境、Goランタイムのように独自の除外リストを内蔵している構成、コンテナイメージ内に埋め込まれたルート証明書バンドルを参照している構成が存在します[50, 51]。Amazon Linuxのパッケージ更新とGoのcrypto/x509更新が別系統の適用経路であるように、利用しているOS、コンテナベースイメージ、実行環境ランタイム、SDKのそれぞれについて、証明書バンドルの所在と最新パッチの適用状況を照合する必要があります[50, 51]。

クライアント通信を行うアプリケーション側の失効検証ポリシーの点検も重要です。失効確認をfail-closedで厳格に実施している通信経路であれば安全性が保たれますが、soft-fail設定や失効未確認で通信を行っている場合は、トラストストアおよびランタイムの早期更新が求められます[50, 51]。AWSは影響を受ける可能性のあるリソースに対してPersonal Health Dashboard（AWS Health）を通じて個別に通知を発信しています[50]。運用者はAWS Healthの通知を確認しつつ、自社のCloudFrontオリジンやALB IdPの証明書チェーン、各種クライアントのトラストストア更新状況を順次照合して、計画的な移行判断を進めることが推奨されます[50, 51]。