eMudhraの証明書問題。ブラウザが正規サイトを見分ける仕組みと影響
公開日 ・更新日
2026年10月、インドの認証局eMudhraをめぐり、HTTPSの信頼を支える中間認証局の秘密鍵が弱い状態で作られていた問題が公表されました。CERT-Inのアドバイザリによると、影響を受けた8件のP-384楕円曲線秘密鍵は、暗号学的な乱数が不足し、公開鍵からほぼ瞬時に復元できる値でした。P-384のアルゴリズム自体の欠陥ではなく、鍵生成手順の問題です。
鍵を復元できる攻撃者は、対象ドメインを管理していなくてもTLS証明書を発行できます。その証明書を使って正規サイトになりすまし、攻撃者が通信経路に入れる環境では、HTTPS通信の横取りや書き換えにつなげられます。eMudhraは、影響を受けた中間認証局からエンドエンティティ証明書は発行されておらず、ルートCAの秘密鍵やインド国内の電子署名サービスは影響を受けていないと説明しています。公開情報だけでは、実際に悪用されたかは確認されていません。
ブラウザが迷う理由
ブラウザは、証明書の対象名、署名のつながり、有効期間、信頼ストアなどを検証して接続先を判断します。つまり、信頼された認証局の秘密鍵で正しいドメイン名の証明書が作られ、端末がその認証局をまだ信頼している間は、証明書の形式だけから攻撃者を見抜けない場合があります。鍵マークは通信路と発行経路の検証結果を示すもので、ページの内容や運営者の意図まで保証する表示ではありません。
今回、Googleは8件の中間認証局の公開鍵に対応するSPKIをChromeのCRLSetでブロックし、ブラウザの再起動や更新を待たずに保護を適用したと説明しています。MozillaもFirefoxのOneCRLで対象証明書をブロックしました。Googleは、ブロック前に6件のTLS中間認証局から発行された証明書がCertificate Transparencyログに記録されていなかったとも説明しています。これはCTを検証するクライアントへのリスクを抑える材料ですが、すべての通信プログラムが同じ仕組みを使うわけではありません。
利用者が先にすること
利用者は、ブラウザとOSを最新状態へ更新し、証明書の警告を無視して進まないことが基本です。更新後も警告が出る場合は、接続先の名前だけでなく、発行元と中間証明書を確認します。業務端末や専用アプリは独自の信頼ストアを持つことがあるため、アプリや端末の更新情報も確認します。
サイト運営者は、自社ドメインの証明書がどの中間認証局とルート証明書につながっているかを棚卸しします。対象の信頼ストアから外れる認証局を使っている場合は、別の公開PKIから証明書を取り直し、CDN、ロードバランサー、オリジン、APIの各接続で反映を確認します。ニュースを読むだけで終わらせず、自社の接続先と利用者の環境へ落とし込むことが重要です。
HTTPSの信頼関係を確認し、利用者に見える警告と裏側の接続をまとめて点検したい方は、COZITOへご相談ください。
関連記事
著者: 松井 勇樹