戻る

2026/10/30

ブラウザーは数時間で保護された。では企業のJavaは？ eMudhra証明書インシデントへのLOGIQの対応

侵害されたeMudhra中間証明書をブラウザーは数時間で遮断しましたが、JDKは独自のトラストストアを持ちます。Azul・BellSoftの提供内容、LOGIQの対応、今確認すべき点を解説します。

要点

  • 2026年10月17日、Mozillaは、eMudhraの中間CA証明書8件の秘密鍵が侵害されたという報告を受けました。ブラウザーは数時間から数日のうちにこれらを遮断しました。eMudhraは、鍵が悪用された証拠は把握していないとしています。
  • Javaは、ブラウザーやオペレーティングシステムの信頼判断を利用しません。すべてのJDK、そしてJDKを同梱するすべてのコンテナイメージやアプリケーションは、それぞれ独自のトラストストアを持っています。そのため、それぞれを個別に更新する必要があります。
  • Azulは10月21日と10月24日の2回、定例外のZulu更新をリリースしました。2回目の更新は最初の修正が不十分だったために出されたものであり、10月21日の回避策だけではもはや十分ではありません。
  • BellSoftは、Java 8、11、17、21、25、27向けの修正済みLibericaビルドを公開しています。LOGIQはBellSoftのサポートチャネルを通じてこれらのビルドを入手し、お客様に提供しました。
  • 対応すべきこと：稼働しているすべてのJavaランタイムを洗い出し、正確なベンダーとビルドを確認し、そのベンダーの修正済みビルドに移行し、TLS接続をテストし、定例外リリースを引き続き注視してください。

何が起きたのか

2026年10月17日（土）20:06（UTC）、Mozillaは、eMudhraの中間証明書8件の秘密鍵が侵害されたという報告を受けました。Mozillaは中央失効リストであるOneCRLを通じてFirefoxでこの8件の証明書を遮断し、標準設定のユーザーには3時間足らず後の22:59（UTC）までに更新が届きました。Mozillaは10月20日にこのインシデントを公表しました。また、設定によってOneCRLの更新が阻まれていたユーザー向けにFirefoxのポイントリリースを提供し、これらの中間証明書に署名したルート証明書をNSSのトラストストアから削除しました。

リスクは証明書の偽造です。これらの鍵のいずれかを持つ者は、自分が管理していないサイトのHTTPS証明書を発行できます。さらにクライアントとそのサイトの間に割り込むことができれば、そのサイトになりすまし、通信を盗聴したり改ざんしたりできます。

現時点で、そのようなことが起きたという証拠はありません。eMudhraはインシデントに関する声明の中で、8件の中間証明書は10月18日に失効済みであり、いずれもエンドエンティティ証明書を一切発行していなかったと述べ、「問題が公表される前に、脆弱な鍵が何者かによって復元または悪用されたという証拠は把握していない」としています。eMudhraは原因について、2025年の鍵生成セレモニーで生成された脆弱な鍵だと説明しています。正確な根本原因はまだ確認できておらず、調査は継続中としています。ブラウザーのルートプログラムは、予防措置として、これらの中間証明書の上位にあるeMudhraのルートを信頼しない措置をとりました。

つまり本記事は、確認された攻撃についてではなく、露出期間をいかに閉じるかについての記事です。

Javaに独自の修正が必要な理由

ブラウザーやオペレーティングシステムには、認証局を信頼しないようにする自動的な仕組みがあり、今回もそれが迅速に使われました。Azulによるインシデントの説明によると、Chromeは同日に、Appleは10月19日に、Microsoftは10月20日にこれらの証明書を遮断しました。

Javaはこれらを一切引き継ぎません。JDKは、どの証明書を信頼するかを自身のファイルに基づいて判断します。

  • 独自のトラストストア。すべてのJDKは独自のcacertsファイルを同梱しています。オペレーティングシステムの証明書バンドルを更新しても、ブラウザーを再起動しても、このファイルは変わりません。
  • デフォルトでは失効確認を行わない。Azulのドキュメントが述べているとおり、Javaはこれらの中間証明書がチェーンするルート証明書を信頼しており、「デフォルトでは失効を確認しない」のです。eMudhraが中間証明書を失効させただけでは、Javaクライアントは保護されません。
  • 多数のコピー。1台のサーバー上で、システムのJDK、アプリケーションに同梱されたJDK、jlinkで作成したランタイム、複数のコンテナイメージが動いていることがあり、それぞれがトラストストアのコピーを持っています。各コピーは、更新または再ビルドされるまで危険にさらされたままです。

そのため、外部へTLS通信を行うJavaサービスは、社内のすべてのブラウザーが保護された後でも、偽造された証明書を受け入れてしまう可能性があります。本記事が扱うのは、このギャップです。

Azulによる2回の緊急更新

Azulは、10月の定例四半期リリースの後、Azul Zulu向けに2回の定例外更新をリリースしました。

  • 10月21日：1回目の定例外更新では、侵害された8件の中間証明書をJDKのブロックリスト（JDK 11以降はblocked.certs、それより古いバージョンではblacklisted.certs）に追加しています。対象はZulu 27、25、21、17、11、8、7、6です。AzulのCVEリストでは、CVE-2026-91403として記録されています。すぐに更新できないランタイム向けに、Azulはブロックリストファイルを置き換える手動の回避策も公開しました。
  • 10月24日：Azulは、ブロックリストでは問題を完全には解消できないことを突き止めました。2回目の定例外更新は、特定のCA証明書をcacertsから完全に削除することで、CVE-2026-114820（JSSE、基本スコア9.1）を修正しています。本記事の執筆時点で、これらのビルドはAzulのセキュリティ修正のみのCPU系列向けに、2026年10月のCPUベース（例：Zulu 21.53.114、17.69.114、11.91.114、8.97.0.112）と2026年7月のCPUベースの両方で提供されています。AzulはPSUビルドについて、別の更新で「おそらく」続くとしています。

10月24日の更新によって、推奨事項が変わりました。Azulの回避策のページには現在、この回避策は「もはや問題に完全には対処できない」との警告が記載されており、Azulはすべての顧客に最新リリースへの更新を求めています。10月21日の更新や回避策を適用済みの場合でも、10月24日のビルドが必要です。Azulは自社の解説記事の中で、リスピンを決定してからセキュリティ修正のみのビルドが顧客の手に渡るまで約12時間だったと述べています。

BellSoftがLiberica JDK向けに提供したもの

BellSoftは10月21日に、定例の2026年10月のLiberica JDKリリースを公開しました。この四半期リリースでは52件のCVEが修正されており、Java 6および7向けのCPUビルド（6u521と7u521）も含まれています。このリリースノートでは、eMudhraの問題は扱われていません。

BellSoftは、eMudhraについて別のガイド「Distrusting compromised eMudhra intermediates in Java」（最終更新10月27日）で取り上げています。このガイドでは、修正済みビルドとしてLiberica JDK 8u513+9、11.0.33.0.3+7、17.0.21.0.3+5、21.0.13.0.3+5、25.0.5.0.3+5、27.0.1.0.3+5が挙げられています。まだ更新できないシステム向けには、影響を受けるルートをトラストストアから削除するという一時的な緩和策が示されています。ただし、これにより正当な証明書チェーンが壊れる可能性があるため、事前にテストすべきだと注意喚起しています。

ベンダーを比較する際に重要な点が2つあります。

  • CVEリストは同じではありません。AzulとBellSoftはそれぞれ10月サイクルの独自のCVEリストを公開しており、件数や注記は異なります。上記のAzulの2つのCVE IDはAzulの記録によるものです。BellSoftのガイドではこれらは引用されていません。お使いのビルドに含まれる正確な修正内容は、ご利用のベンダーのリリースノートで確認し、あるベンダーのリストが別のベンダーのJDKにも当てはまると想定しないでください。
  • Java 6と7は、BellSoftのeMudhraリストに含まれていません。BellSoftの最新のJava 6および7ビルドは提供されていますが、eMudhraガイドにある修正済みビルドのリストはJava 8から始まっています。Liberica 6または7を使用している場合は、それに頼る前に、お使いのビルドにトラストストアの変更が含まれているかを問い合わせるか、ベンダーの緩和策を適用してください。Azulは、Zulu 6および7向けの10月24日のビルドを公開しています。

LOGIQの対応

当社は、BellSoftとAzulのJavaビルドをお客様に提供し、古いOracle JDKバージョンからの移行を支援しています。以下は当社が実施した内容と、執筆時点（10月29日）における各項目の状況です。

完了済み

  • 10月21～22日：ベンダーの通知を確認。Azulの10月21日の定例外リリースの通知と、BellSoftの2026年10月リリースの通知を受け取り、内容を確認しました。同日中に、両ベンダーについてダウンロードとリポジトリ登録のタスクを起票しました。2つのリリースは別々に扱い、BellSoftの四半期リリースにAzulと同じeMudhraの修正が含まれているとは想定しませんでした。
  • 10月23日：Libericaの四半期ビルドを準備。BellSoftのサポートポータルから2026年10月のLiberica JDKビルドをダウンロードし、お客様がダウンロードに使用するリポジトリに追加しました。
  • 10月24～25日：Azulの2回目の更新を追跡。10月21日のビルドを導入済みでも更新すべきという推奨を含め、Azulの10月24日の通知を把握しました。
  • 10月27～28日：BellSoftを通じて修正済みLibericaビルドを入手。商用サポート契約を通じて、最新ビルドを当社のサポートポータルで提供するようBellSoftに依頼しました。BellSoftは10月28日に、Java 8、11、17、21、25、27向けの修正済みビルドと、最新のJava 6および7ビルドを含めてアップロードしました。32ビット版のJava 8を必要とするお客様もいらっしゃるため、Windows版とLinux版の32ビット8u513+9インストーラーをポータルに追加するようBellSoftに依頼し、BellSoftは同日中に追加しました。
  • 10月28～29日：リポジトリと移行対応表を更新。これらのビルドをお客様向けダウンロードリポジトリに追加し、Oracle JDKからLibericaへの移行ガイダンスをこれらのビルドを示すように更新しました。更新内容は2人目のエンジニアがレビューしました。

Azul Zuluをご利用のお客様

Azulの10月21日および10月24日のビルドは、Azulのサブスクリプション契約者にAzulを通じて提供されています。適切なビルドは、Javaのバージョン、CPU系列とPSU系列のどちらを使用しているか、どのベース（10月または7月）を使用しているかによって異なります。お使いのビルドについてはAzulのリリースノートをご確認いただくか、当社にお問い合わせいただければ特定をお手伝いします。

レガシーなJava 6と7

Java 6や7を今も使用しているお客様もいらっしゃいます。多くの場合、すぐには移行できないアプリケーションです。Oracleはこれらのバージョンの公開アップデートをすでに提供していませんが、選択肢がないわけではありません。当社は、古いOracle JDK 6および7のビルドから最新のLiberica JDK 6および7のビルドへの移行を支援しており、両バージョンのBellSoftの2026年10月ビルドは、BellSoftのサポートポータルを通じて当社が入手できます。これらのバージョンで必要な修正やパッケージが欠けている場合は、商用サポートチャネルを通じてBellSoftにエスカレーションします。今回のインシデントについては上記の注意点をご参照ください。それに頼る前に、お使いのJava 6または7のビルドにeMudhraのトラストストア変更が含まれていることを確認してください。

今すぐ実施すべきこと

1. すべてのJavaランタイムを洗い出す

システムのJDKだけでなく、Javaが動作しているすべての場所をリストアップしてください。これには、アプリケーションサーバー、ベンダー製品に同梱されたランタイム、jlinkイメージ、CIのビルドエージェント、そしてすべてのコンテナイメージが含まれます。Linuxでは、次のコマンドでホスト上のJavaバイナリを見つけられます。

find / -xdev -type f -path "*/bin/java" 2>/dev/null

コンテナイメージの場合は、イメージ内で確認を実行してください。例：docker run --rm --entrypoint java <image> -version

2. 正確なベンダーとビルドを確認する

メジャーバージョンだけでは不十分です。ベンダーの修正済みビルドのリストと照合するには、ベンダーと完全なビルド番号が必要です。

java -XshowSettings:properties -version 2>&1 | grep -E "java.vendor =|java.runtime.version|java.home"

簡易的な目安として、ランタイムのトラストストアにあるeMudhra（emSign）のルートを一覧表示することもできます。

keytool -list -keystore "<java.home>/lib/security/cacerts" -storepass changeit | grep -i emsign

BellSoftの公開コンテナイメージを使った当社のテストでは、古いLiberica 21.0.10ビルドではemSignのルートが5件表示されましたが、修正済みの21.0.13.0.3+5および8u513ビルドでは1件も表示されませんでした。結果が空であることは良い兆候ですが、証明にはなりません。たとえば、Azulの10月21日の修正は、ルートを削除せずに中間証明書を遮断するものでした。確実な確認方法はビルド番号です。より詳しい確認方法については、Javaのトラストストアの確認に関する以前の記事をご覧ください。

3. 該当する最新のパッチを適用する

  • Azul Zulu：10月21日のビルドを導入済み、または回避策を適用済みであっても、ご利用の系列（CPUまたはPSU、10月または7月ベース）向けの10月24日の定例外ビルドに移行してください。PSUビルドをご利用の場合は、Azulによる今後のPSUリリースを注視してください。
  • Liberica JDK：BellSoftが挙げている修正済みビルド（8u513+9、11.0.33.0.3+7、17.0.21.0.3+5、21.0.13.0.3+5、25.0.5.0.3+5、27.0.1.0.3+5）に移行してください。
  • その他のベンダーや同梱ランタイム：該当ベンダーのアドバイザリを確認してください。サードパーティ製品内のJDKは、OSの更新ではなく、その製品のベンダーによって更新されます。
  • コンテナ：修正済みのベースイメージでイメージを再ビルドし、再デプロイしてください。実行中のコンテナにパッチを当てても、イメージは変わりません。

4. 展開前および展開中にTLSを検証する

トラストストアからルートを削除すると、正当な接続が切断される可能性があります。たとえば、削除されたeMudhraのルートにチェーンする証明書を今も使用しているサイトへの接続です。eMudhraは、影響を受ける顧客の証明書を代替のCA階層から再発行しているとしています。大規模に展開する前に、アプリケーションが依存している外部へのTLS接続、特にeMudhraの証明書を使用している可能性のある取引先やサービスへの接続をテストしてください。段階的に展開し、新しいトラストストアを読み込むようJavaプロセスを再起動し、その後、実行中のバージョンを確認してください。

5. 定例外リリースを注視する

今回のインシデントでは、4日間で2回のJava緊急リリースが出され、AzulのPSUビルドなど、さらに続く可能性があります。ベンダーのセキュリティ通知を購読し、メールだけに頼らずリリースページを直接確認し、四半期スケジュール外のJava更新にも備えて計画を立ててください。

教訓

Firefoxのユーザーが数時間以内に保護されたのは、ブラウザーが独自のトラストストアと、それを自動的に更新する仕組みを持っているからです。企業のJavaには多数のトラストストアがあり、デフォルトでは失効確認が行われず、更新は誰かがインストールするまで適用されません。このギャップを埋めるには、正確なインベントリ、正確なビルド番号、ベンダーのビルドへの迅速なアクセス、そして次の四半期パッチを待たないプロセスが必要です。お使いの環境でJavaランタイムの特定や更新にお困りの場合は、LOGIQにお問い合わせください。

参考資料