eMudhra中間CAの侵害: 自社環境で影響を受ける証明書を特定する方法

ブラウザに表示されるすべての鍵マークは信頼の連鎖（Chain of Trust）に基づいており、その連鎖の強さはそこに含まれる最も脆弱な秘密鍵と同等でしかありません。今月、あるチェーンにおける8つのリンクが推測可能であることが判明しました。

本日は2026年10月26日です。10月17日、あるセキュリティ研究者が、認証局（CA）であるeMudhraの8つの中間証明書の秘密鍵が復元可能であると報告しました。これらの証明書は失効され、主要なブラウザおよびOSベンダーによってブロックされています。この問題はCVE-2026-111943およびCVE-2026-111944として追跡されています。今週セキュリティチームが緊急で行うべき対応は、言うのは簡単ですが実行するのは骨の折れる作業です。自社環境のどこかにこれらの証明書が存在していないか、また自社のソフトウェアがそれらを依然として信頼していないかを調査することです。

証明書チェーンの基礎知識のおさらい

HTTPS経由でウェブサイトにアクセスすると、サーバーは自身のドメイン名に対する リーフ証明書 を提示します。その証明書は 中間CAによって署名されており、その中間CAは ルートCAによって署名されています。ブラウザやOSには信頼するルートの一覧が同梱されており、これを トラストストアと呼びます.

ルート鍵はオフラインで保管され、厳重に保護されています。日常的な署名作業は中間CAが行います。問題は、中間CAの秘密鍵を持つ者であれば誰でも任意のドメイン名に対して証明書に署名でき、そのチェーンを信頼するクライアントは通常それを受け入れてしまうという点です。そのため、不正な証明書がまだ確認されていなくても、中間鍵の漏洩は深刻な事態となります。

報告されている事象の経緯

公開された開示情報およびベンダーの報告によると、経緯は以下の通りです:

• 2025年4月30日の鍵生成セレモニーにおいて、eMudhraは24の下位CAの鍵を生成しました。
• wrap/unwrap処理の不具合により、脆弱なP-384鍵の2つ目のセットが生成されました。P-384は非常に広大な鍵空間を提供するはずの楕円曲線です。
• それらの脆弱な鍵が誤って8つの中間証明書に使用されました。有効なランダム性（エントロピー）はおよそ3〜8ビットと報告されており、これは可能な鍵の数がせいぜい数百通りしかないことを意味します。コンピュータにとって、それらを復元することは極めて容易です。
• 8つのうち6つはTLS中間CAであり、2つはコード署名用中間CAです。

報告されている対応状況:

• Chrome、Mozilla、Appleは6つのTLS中間CAをブロックしました。Microsoftは2つのコード署名用中間CAをブロックしました。
• GoogleはChrome Root StoreからemSign ECC Root CA - G3を削除し、Mozillaはこれらの中間CAに署名したルートに対する信頼を取り消しました。
• eMudhraは8つの証明書を失効させ、G3ルート配下での発行を停止しました。同社は、ルート秘密鍵およびその他の中間CAは影響を受けていないこと、本問題はグローバルなウェブサイトセキュリティ事業に限定されておりインド国内のDSCおよびeSignサービスには影響しないこと、影響を受ける中間CAのうち本番環境で使用されていたのは1つのみであり、ウェブサイトやエンドユーザー向けに証明書を発行した中間CAは存在しないと述べています。

ベンダーの声明はあくまでベンダー側の主張として受け止めてください。皆様の責務はインシデントの是非を判断することではなく、自社環境への影響の有無を確認することです。

まず確認すべき対象

以下に該当する場合は、優先的に対応リストの上位に置く必要があります:

• インターネットに公開されているウェブサイト、API、VPN、またはその他のTLSサービスを運用している場合。
• eMudhraまたはemSignの階層を通じてパブリックに信頼された証明書を購入している場合。
• パブリックなコード署名証明書に依存する署名済みソフトウェアを配布・提供している場合。
• Go言語で記述されたアプリケーションをビルドまたは実行している場合。
• 信頼取り消し（distrust）の更新を自動的に受信しないレガシーシステム、管理外のエンドポイント、アプライアンス、またはカスタムトラストストアを管理している場合。

影響を受ける8つの中間CA

SHA-256フィンガープリントとシリアル番号は、証明書を照合する最も確実な方法です。名前は偽装できますが、フィンガープリントは偽装できません。

証明書	タイプ	シリアル番号	SHA-256フィンガープリント
EM EV TLS CA - G3B (eMudhra BV)	TLS	c7c41efe92d825f05eae841a4a82c1	E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
EM OV TLS CA - G3B (eMudhra BV)	TLS	6cada367fb1c100088120ea202d568	98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
EM DV TLS CA - G3B (eMudhra BV)	TLS	a4aee678f23362b4c0e460b772f214	42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
EM EV TLS CA - G3C (eMudhra Inc)	TLS	8009928a64107601af05fa2f19f109	432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
EM OV TLS CA - G3C (eMudhra Inc)	TLS	296926c227a3a1526392b19482a504	CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
EM DV TLS CA - G3C (eMudhra Inc)	TLS	588b2e3c2bb8cda13e1a1209254321	0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
EM OV CS CA - G3B (eMudhra BV)	Code signing	7818933f8f85b4619a2b35fba83d0a	9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
EM OV CS CA - G3C (eMudhra Inc)	Code signing	544b7f922c31ae220a4a922916f6e6	4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1

それらを特定する方法: 段階的なチェック手順

影響の範囲には2つの側面があります。1つは自社のサーバーが提示している証明書、もう1つは自社のソフトウェアが依然として信頼している証明書です。以下の手順では、まず標準的なオープンソースツールを使用し、次に商用スキャナーをすでに導入しているチーム向けの手法を用いて、その両方をカバーします。

ステップ 1: TLS通信を行うすべての対象をリストアップする

一覧化されていないものをチェックすることはできません。パブリックドメイン、内部サービス名、ロードバランサー、VPNゲートウェイ、および自社名義を使用しているサードパーティホストのサイトをすべて洗い出してください。リモート勤務者のノートPCや隔離されたネットワークなど、スキャナーが到達できないサーバーも含めます。そうした対象を把握するには、ホスト上のエージェントが唯一の手段であることがよくあります。

ステップ 2: 各サーバーが提示するチェーンを確認する

単一のホストについては、OpenSSLを使用してサブジェクト、発行者、シリアル番号、フィンガープリントを含むチェーン内の全証明書を出力できます。 app.example.com をご自身のホストに置き換えてください:

HOST=app.example.com
echo | openssl s_client -connect "$HOST:443" -servername "$HOST" -showcerts 2>/dev/null \
  | awk '/-----BEGIN CERTIFICATE-----/{n++; f=1} f{print > ("chain-" n ".pem")} /-----END CERTIFICATE-----/{f=0}'

for f in chain-*.pem; do
  openssl x509 -in "$f" -noout -subject -issuer -serial -fingerprint -sha256
  echo
done

OpenSSLはシリアル番号を大文字で、フィンガープリントをコロン区切りで出力するため、大文字小文字やコロンを無視して比較してください。8つのリストに対する簡易マッチングコマンドは以下の通りです:

for f in chain-*.pem; do
  openssl x509 -in "$f" -noout -fingerprint -sha256 | cut -d= -f2 | tr -d ':'
done | grep -i -E 'E7568FE6|98B89662|42C4ACCD|432EC25F|CB6E1516|0164D7CE|9E39DE28|4B2460A4' \
  && echo "MATCH: affected intermediate found" || echo "No affected intermediate in this chain"

プレフィックスによる検索は高速なフィルタにすぎません。一致するものが見つかった場合は、対処を行う前に表の完全なフィンガープリントと照合してください。ホスト一覧に対してこの処理をループ実行することで、基本的な一括スキャンが可能です。

ステップ 3: 脆弱性スキャナーを運用している場合の大規模な検索

組織ですでにQualys VMDR with Certificate Viewを使用している場合、Qualysからすぐに使えるクエリが公開されています。Certificate Viewにおいて、発行者名（issuer name）で検索すれば8つすべてをカバーできます:

certificate:(issuer.name:[`EM EV TLS CA – G3B`, `EM OV TLS CA – G3B`, `EM DV TLS CA – G3B`, `EM EV TLS CA – G3C`, `EM OV TLS CA – G3C`, `EM DV TLS CA – G3C`, `EM OV CS CA – G3B`, `EM OV CS CA – G3C`])

より広範なチェックとして、影響を受ける中間CAに記載されている2つのeMudhra組織の配下で発行されたすべての証明書をリストアップします:

certificate:(issuer.organization:`eMudhra BV` or issuer.organization:`eMudhra Inc`)

Qualysは、影響を受けるGoバージョン向けのQID 5019897と、8つの中間CAを含むチェーンを列挙する情報収集チェックであるQID 48395もリストしています。これらを利用する前に、エージェントが最新のシグネチャを保持していることを確認してください。クエリートークンは大文字と小文字が区別されるため、クエリでエラーが発生した場合は製品ヘルプを参照してください。他のスキャナーにも同様の機能があります。表に記載されたフィンガープリントはあらゆるツールで有効です。

ステップ 4: 不正なチェーンを依然として信頼しているGoプログラムを特定する

これが見落とされがちな部分です。自社のサーバーに問題がなくても、自社のアプリケーションが偽造された証明書を受け入れてしまう可能性があります。アドバイザリによると、Go 1.27.3および1.26.10では、これら8つの鍵のいずれかを含むチェーンがブロックされます（CVE-2026-111943）。Goプログラムには独自の証明書検証コードが含まれているため、古いGoでビルドされたプログラムは再ビルドされるまで従来の挙動を維持し続けます。

ビルドマシン上のツールチェーンを確認する:

go version

すでに実行中のバイナリをどのGoバージョンがビルドしたかを確認する:

go version /usr/local/bin/your-service

古いリリースでビルドされたものはすべて、修正済みGoバージョンで再ビルドして再デプロイする必要があります。また、複数のディストリビューションが独自にパッチを適用したGoパッケージを提供しているため、OSベンダーのアップデートも適用してください。

ステップ 5: 交換、更新、そして継続的な監視

• まず交換を行う。 チェーンにこれら8つのいずれかを含むリーフ証明書は、別の信頼できるCAから再発行を受け、正しいチェーンで再デプロイする必要があります。
• アップデートを実施する。 OSのセキュリティアップデートを適用し、Goランタイムを修正済みリリースへ移行してください。
• 失効チェックが機能していることを確認する。 失効情報は、実際にそれをチェックするクライアントでのみ有効です。カスタムトラストストア、アプライアンス、古いJava環境や組み込みシステムでは、中間CAを手動で削除するか、明示的に信頼を取り消す必要がある場合があります。
• 継続的に監視する。 検索条件をスケジュール済みジョブまたはダッシュボードとして保存し、スキャンの結果がクリーンな状態を維持するまで、スキャンのたびに再実行してください。

まとめ

eMudhraのインシデントは、インターネット上の信頼が「自身が提示する証明書」と「信頼することを選択した認証局」という2つの要素に依存していることを再認識させるものです。修正手順は決して特殊なものではありません。TLSエンドポイントをリストアップし、既知の8つのフィンガープリントとチェーンを照合し、修正済みツールチェーンでGoプログラムを再ビルドし、古いシステムが失効情報を確実に受け取っているか確認してください。今週中にこれらを実施し、その後もチェックを継続してください。

メリット

• 影響を受ける証明書は正確なフィンガープリントを持つ短い固定リストであるため、照合が正確に行えます。
• 主要なブラウザおよびOSがすでにこれらをブロックしているため、一般的なユーザーの多くは自動的に保護されます。
• OpenSSLや go version などの無料ツールで基本的なチェックには十分です。
• 既存のスキャナーを使用すれば、この調査を反復可能なダッシュボードに統合できます。
• この対応を通じて証明書インベントリが改善され、将来のインシデントへの備えとなります。

デメリット

• カスタムまたは固定されたトラストストアを持つシステムは、手動での対応を行わない限りベンダーのブロックリストの恩恵を受けられません。
• Goバイナリは再ビルドが必要です。ツールチェーンを更新するだけでは、すでにデプロイ済みのプログラムは修正されません。
• ネットワークスキャンでは到達できないホストが見落とされるため、エージェントの導入や手動による確認が必要です。
• 失効チェックを行わないクライアントに対しては、証明書失効は効果がありません。
• アプライアンスやサードパーティホストのサイトにおける証明書の交換には、時間がかかりベンダーの支援が必要になる場合があります。

注意

本記事は教育および一般的なガイダンスを目的としています。 app.example.com などのホスト名や /usr/local/bin/your-service などのパスはプレースホルダーであり、ご自身の環境の値に置き換える必要があります。インシデントの詳細は、上記の日付時点における公開レポートおよびベンダーの声明を要約したものであり、変更される可能性があります。ブラウザ、OS、Go、スキャナーの各ベンダーによる最新のアドバイザリを確認し、一致が見つかった場合に対処する前には、信頼できる情報源と照らし合わせてすべてのフィンガープリントを検証してください。

よくある質問（FAQ）

• eMudhra中間CAの侵害とはどのようなものですか？ — eMudhraの8つの中間証明書が、秘密鍵を復元可能な脆弱なP-384鍵で生成されていたため、2026年10月に失効され、主要ベンダーによってブロックされました。
• この問題はどのCVEで追跡されていますか？ — CVE-2026-111943およびCVE-2026-111944として追跡されています。影響を受けるチェーンをブロックするGoの修正はCVE-2026-111943に記載されています。
• インド国内のDSCおよびeSign証明書は影響を受けますか？ — eMudhraは、本問題はグローバルなウェブサイトセキュリティ事業に限定されており、インド国内のDSCおよびeSignサービスには影響しないと述べています。
• 自社のウェブサイトが影響を受ける中間CAを使用しているか確認するにはどうすればよいですか？ — コマンド openssl s_client -showcertsでチェーンを取得し、各証明書のSHA-256フィンガープリントを出力して、上記の8つのフィンガープリントと比較します。
• なぜGoアプリケーションには特別な注意が必要なのですか？ — Goプログラムには独自の証明書検証処理が含まれているため、影響を受けるチェーンを拒絶するには、Go 1.27.3または1.26.10（あるいはそれ以降の修正済みリリース）で再ビルドする必要があります。
• 安全を確保するには失効だけで十分ですか？ — 必ずしも十分ではありません。失効チェックを一切行わないクライアントも存在するためです。カスタムトラストストアや古いシステムでは、手動で証明書を削除するか信頼を取り消す必要がある場合があります。
• 影響を受ける証明書が見つかった場合はどうすればよいですか？ — 別の信頼できるCAからリーフ証明書を再発行し、正しいチェーンでデプロイした上で、再スキャンを行い古いチェーンが排除されたことを確認してください。
• これに脆弱性スキャナーを使用できますか？ — はい。Qualys Certificate Viewなどのツールは発行者やシリアル番号による検索を提供しており、証明書のフィンガープリントを記録するスキャナーであれば、ここに挙げた8つの証明書を照合できます。

タグ

#eMudhra #CertificateAuthority #TLS #PKI #CVE2026111943 #CyberSecurity #GoLang #VulnerabilityManagement #CodeSigning #Qualys