中間CAの危殆化・失効で自分のサイトの証明書はどうなる？確認手順とeMudhra事例

中間CA（中間認証局）が危殆化・失効すると、有効期限内で何も問題のない自分のサイトの証明書まで、ブラウザやアプリの検証に失敗することがあります。2026年10月には eMudhra（emSign）の中間CA 8件の秘密鍵が危殆化し、各トラストストアがブロックしました。この記事は、なぜ自分の証明書が巻き込まれるのか、自分のチェーンが問題の中間CAを使っていないかの確かめ方、失効への対処を、openssl で手を動かしながらまとめます。

今回の件は、ソフトウェアの信頼の起点が揺らいだ例です。依存部品やビルドまで含めた信頼の広い話はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめています。

中間CA・ルート証明書が失効・危殆化すると、有効な証明書はどうなるか

TLS の証明書は1枚で成り立っているのではありません。ブラウザやアプリは、サーバーが送ってきた端末の証明書（サーバー証明書）から、それを発行した中間CA、さらにその上のルート証明書へと、署名の鎖をたどって信頼を確かめます。ルート証明書は OS やブラウザに最初から入っている信頼の起点です。

鎖の途中にある中間CAが信頼されなくなると、その中間CAから下の証明書は、鎖の行き先を失います。端末の証明書が有効期限内で、設定も何も変えていなくても、検証は失敗します。自分のサーバーの不備ではなく、信頼の鎖の途中が外から無効化されたために起きる点が、この問題の分かりにくいところです。

中間CAを無効にする方法は、トラストストア（信頼ストア）によって違います。

・失効（revocation）：認証局が証明書を失効させ、CRL や OCSP で「もう有効ではない」と公表する。ただし検証する側が失効情報を見ない実装もある
・ブロックリスト：Mozilla の OneCRL や Chrome の CRLSet のように、ブラウザが問題の証明書を配布物として直接ブロックする。更新は自動で届く
・信頼ストアからの削除：ルート証明書そのものを信頼ストアから外す。NSS や certifi のルート一覧の更新がこれにあたる

このうちどれが効くかは、相手が使っているブラウザ・OS・言語で変わります。だからこそ、自分の証明書がどの中間CAから発行されているかを先に把握しておくことが対処の出発点になります。

何が起きたのか：eMudhra（emSign）の中間CA 8件の鍵の危殆化

2026年10月、インドの認証局 eMudhra が運用するブランド emSign の中間CA 8件（TLS 用6件・コード署名用2件）について、秘密鍵が危殆化したと研究者が報告しました。各トラストストアの対応は数日のうちに相次ぎました。日時は各出典の表記に合わせています。

秘密鍵が危殆化した中間CAを持つ攻撃者が何をできるかは、攻撃者が得たものと、通信経路に割り込めるかで変わります。

自分の証明書チェーンが問題の中間CA（emSign）を使っていないか確かめる

ここからは openssl で確かめます。環境は OpenSSL 3.0.13 です。自作のルート→中間→端末の3段の擬似チェーンを作り、中間CA の CN に emSign を含む陽性と、含まない無関係の陰性の両方で、下の3つが掲載したままの形で動くことを確かめました。

① サーバーが送るチェーンの発行者（issuer）

接続先が送ってくる証明書を1枚ずつ取り出し、それぞれの subject と issuer に emSign / eMudhra が出るかを見ます。

# 自分のホスト名とポートに置き換える
host="www.example.com"; port=443

# サーバーが送ってくる証明書を1枚ずつファイルに分ける（前回の分は消す）
rm -f chain*.pem
openssl s_client -connect "$host:$port" -servername "$host" -showcerts </dev/null 2>/dev/null \
  | awk '/-----BEGIN CERTIFICATE-----/{n++; f=1} f{print > ("chain" n ".pem")} /-----END CERTIFICATE-----/{f=0}'

# 1枚ごとに subject・issuer を出し、emSign / eMudhra を含む証明書に印をつける
for c in chain*.pem; do
  line=$(openssl x509 -in "$c" -noout -subject -issuer)
  echo "$line"
  echo "$line" | grep -qi -E 'emsign|emudhra' && echo "  !! emSign/eMudhra に関係: $c"
done

擬似チェーンを出すサーバーに対して、中間CA の CN が emSign Test DV TLS CA - G3B のとき、端末と中間の2枚に印が付きました。無関係のチェーンでは印は付きませんでした。

② 手元にある証明書ファイルの発行者

サーバーに置いた fullchain.pem などが手元にあるなら、ファイルから直接 issuer を読めます。

# サーバーに配置した証明書（fullchain.pem など）の発行者と有効期限を見る
openssl x509 -in fullchain.pem -noout -issuer -subject -dates

emSign の中間CAで発行した端末証明書では issuer に emSign ... が出て、無関係の証明書では別の認証局名が出ました。

③ OS の信頼ストアに emSign のルートが残っていないか

利用者側として、自分の端末の信頼ストアに emSign のルート証明書が残っているかも確かめられます。PEM ファイルの本文は base64 なので、そのまま文字列検索しても発行者名は出ません。各ファイルの subject をデコードして探します（下は Debian / Ubuntu 系の例）。

# 各ルートの subject をデコードして emSign を探す（Debian / Ubuntu 系）
hit=0
for f in /etc/ssl/certs/*.pem; do
  openssl x509 -in "$f" -noout -subject 2>/dev/null | grep -qi emsign && { echo "残っている: $f"; hit=1; }
done
[ "$hit" -eq 0 ] && echo "emSign のルートは信頼ストアに無い"

emSign のルートを置いた一時ディレクトリではその1件が出て、この記事を書いた環境の /etc/ssl/certs（Mozilla ルート124件）では0件でした。信頼ストアに emSign のルートがあるかどうかは OS・ディストリビューション・更新状態で変わるため、件数そのものは環境ごとに違います。macOS（security）や Windows（証明書マネージャー）の信頼ストアは置き場所と確認方法が異なり、本記事では未検証です。

証明書 失効への対処：認証局への再発行とソフトの更新

確認の結果、自分の証明書が問題の中間CAから発行されていた場合、設定で信頼を戻すことはできません。別の認証局（または同じ認証局の別の中間CA）から再発行するのが基本です。

・自社のサーバーの場合：emSign 以外の認証局、または影響を受けていない中間CAから発行し直し、fullchain.pem を差し替える。更新の自動化を整えておくと、次に同じことが起きたときの入れ替えが速い
・相手のサーバーにつながらなくなった場合：③で確かめた発行者の情報を添えて、相手に別の認証局への切り替えを依頼する。自分の端末側の設定では直せない
・プログラムから検証している場合：使っている言語・ライブラリがどの信頼ストアを見るかで対応先が変わる

検証する側の実装によって効き方が違う点は重要です。失効情報（CRL・OCSP）を見ない検証器では、認証局が失効させても接続は止まりません。たとえば Go の標準ライブラリは失効確認をしないため、今回は検証器そのものにコード修正が入りました。詳しくはGo 脆弱性 CVE-2026-111943｜x509がeMudhraの中間CA 8件を拒否、作り直しと確認手順にまとめています。

修正版やブロックがすぐ行き渡らない間の一時的な手当ての考え方は仮想パッチとは｜修正版を当てるまでの数日をWAFで稼ぐ手順と、IDORやカーネルなどWAFでは守れない脆弱性が参考になりますが、今回はクライアント側の証明書検証の話なので、サーバー前段の WAF では守れません。守る側にできるのは、自分のチェーンの把握と、問題の中間CAからの速やかな移行です。

参照ソース

・Protecting Firefox users following the compromise of eMudhra intermediate certificates（Mozilla Security Blog） — 中間証明書8件の秘密鍵の危殆化と Firefox の対応（2026-10-21時点）
・Mozilla Bugzilla 2083449：Private key compromise of eMudhra Intermediate Certificates — インシデントの一次記録
・NSS 3.131.1 release notes — emSign のルート削除
・certifi コミット 662df63（Restore unaffected emSign roots） — Python 側のルート一覧の更新
・The Hacker News：Go Issues Emergency Update Blocking eMudhra Certificate Keys — Chrome・Apple・Microsoft の対応日と Chrome の CT に関する説明（報道）
・emudhra.we-have-a-problem.com — この件を追う非公式のコミュニティ・トラッカー（数値の正は上の一次情報で確かめること）