eMudhraの証明書問題｜Chromeは自動で対応済み、Linuxはca-certificatesの更新が必要

Chromeを使っている人は、eMudhraの証明書問題で何もする必要はありません。Chromeは2026年10月18日（日本時間）の朝までに、秘密鍵がもれたeMudhraの中間CA証明書を自動ではじくようにしていて、ブラウザの更新や再起動も要りません。

Firefoxも同じように対応済みです。LinuxのサーバーやPC、WSL、Dockerイメージを使っている人は、ca-certificates を今回直ったバージョンに更新し、そのバージョンを確かめてください。

結論：Chromeは自動で対応済み、Linuxはca-certificatesの更新が必要

• 何が起きたか：認証局eMudhraの中間CA証明書8枚で、鍵を作るときの乱数が足りず、第三者が秘密鍵を割り出せる状態でした。悪用されると、どのサイトにもなりすませる証明書を作れてしまいます
• Chrome・Firefox：10月18日（日本時間）の朝までに、更新や再起動なしではじくようになっています。使う人の操作は要りません
• Android：Google Play開発者サービスを通じて同じ対応が届いています。すぐに反映したいときは端末を再起動します
• Linux：Debian・Ubuntu・Fedoraは、もとになったルート証明書を外した ca-certificates を出しています。Red Hat Enterprise Linux（RHEL）は、RHEL 10・9・8と、RHEL 7の延長ライフサイクルサポート（ELS）向け、RHEL 6のELS EXTENSION向けの更新を出しています
• サイトを運営している人：自分のサイトの証明書が「emSign ECC Root CA - G3」につながっていなければ、作業はありません

何が起きたか

Mozillaの不具合報告（Bug 2083449）によると、Mozillaは2026年10月17日20時06分（UTC、日本時間では10月18日5時06分）に、eMudhraの中間CA証明書8枚の秘密鍵がもれているという報告を受けました。報告はChromeのルート証明書プログラムから転送されたもので、eMudhraとApple・Microsoftのルート証明書プログラムにも同時に知らされていました。

8枚のうち6枚はTLS（HTTPS）用で、Chrome・Mozilla・Microsoft・Appleのルート証明書プログラムで信頼されていました。残りの2枚はコード署名用で、Microsoftで信頼されていたものです。Mozillaは報告とは別に自分たちでも秘密鍵を割り出せたことから、鍵の作り方そのものに誤りがあったと判断しています。

eMudhraの説明では、8枚は2025年4月30日の鍵生成の作業で作られたもので、その手順の一部の誤りで弱い鍵ができ、それが証明書に使われました。Mozillaの不具合報告では、eMudhraは10月18日（UTC）に8枚をすべて失効させています。同じ鍵を使い、Sectigoが署名した証明書（クロス署名）も、10月19日にSectigoが失効させました。

eMudhraは、8枚のうち7枚は本番では使われておらず、本番で使われていた1枚もサイト向けの証明書を1枚も発行していなかった、としています。

Chrome・Firefox・Androidは自動で対応済み

Chrome

Googleの発表によると、Chromeは10月17日19時45分（UTC、日本時間では10月18日4時45分）に、問題のTLS用中間CA 6枚の鍵をはじく更新（CRLSet）を出しました。鍵ではじくので、Sectigoが署名した同じ鍵の証明書もまとめて止まり、ブラウザの更新や再起動は要りません。

Chromeは、証明書の発行記録を公開する仕組み（Certificate Transparency、CT）に載っていない証明書を受け入れません。Googleによると、この6枚の中間CAにつながるTLS証明書は、止めるまでCTに1枚も載っていませんでした。そのため、CTを確かめるクライアントに対して偽の証明書は使えなかったとしています。

Googleは、8枚に署名したルート証明書「emSign ECC Root CA - G3」もChromeのルート証明書の一覧から外し、その変更を米国太平洋時間の10月27日（火）朝に、Chromeのルート証明書の一覧を使うすべての端末向けに出す見込みだと発表しています（Googleの発表）。Googleによると、このルートにつながる正規の証明書の一部が、Chromeでは使えなくなります。Googleが証明書の入れ替えを求めているのはサイトを運営している側で、Chromeを使う人の操作は要りません。

Firefox

Mozillaは、失効した証明書の一覧（OneCRL）でこの中間証明書をはじき、10月17日22時59分（UTC、日本時間では10月18日7時59分）までに、ふつうの設定のFirefoxすべてに届けました。こちらも更新や再起動は要りません。

設定によってOneCRLを受け取れていない人向けに、10月20日にFirefox 158.0.1（デスクトップとAndroid）、Firefox ESR 115.43.1、Firefox ESR 153.5.1も出ています。Androidでは一部のプロファイルで一覧が起動時に反映されない不具合があり、修正したFirefox 158.0.2が出ています。

Android

Googleによると、AndroidとGooglebookには、Google Play開発者サービスを通じて同じ対応が10月19日22時ごろ（UTC、日本時間では10月20日7時ごろ）に届き始めました。多くの端末にはすでに届いていて、端末を再起動するとすぐに反映されます。

WindowsやMac、iPhoneも、OSの自動更新を止めずに、最新のバージョンを使ってください。

影響が残るのはブラウザ以外のソフト

ブラウザのような失効の一覧を受け取らず、失効情報も確かめないソフトは、信頼するルート証明書の一覧（トラストストア）にもとのルート証明書が入っている限り、問題の中間証明書を信頼したままになります。LinuxでHTTPS通信をするコマンドやプログラムの多くは、OSの ca-certificates を使っています。

Mozillaは、10月20日に出したNSS 3.131.1で、8枚に署名したルート証明書「emSign ECC Root CA - G3」を信頼する一覧から外しました。Firefox自体はOneCRLで守られているものの、Mozillaの一覧やそれをもとにした一覧を使うほかのソフトを守るための変更です。Debian・Ubuntu・Fedoraも、これに合わせて「emSign ECC Root CA - G3」を外しています。DebianとFedora、Ubuntu 20.04 LTS以前では、Sectigo側のクロス署名のもとになった「Comodo AAA Services root」（AAA Certificate Services）も外しています（Ubuntu 22.04 LTS以降には、このルートはもともと入っていません）。

Red Hatも、RHEL 6〜10は ca-certificates にもとのルート証明書が入っているので影響を受けるとし、TLSを使うすべてのRHELで、更新パッケージが出たらすぐに入れるよう勧めています。RHELやUBIをもとにしたコンテナは、ベースイメージが更新されたら作り直すよう求めています。

ルート証明書を外すと、そのルートにつながる正しい証明書を使っているサイトにも、つながらなくなります。更新後に一部のサイトで証明書のエラーが出たときは、相手のサイトの証明書が入れ替わるのを待つことになります。

Linuxのca-certificatesを更新する（Debian・Ubuntu・Fedora・RHEL）

Debian・Ubuntu

直った ca-certificates のバージョンは次のとおりです（Debianのセキュリティ勧告DSA-6572-1・DLA-4845-1、UbuntuのUSN-8944-1・USN-8944-2より）。

OS	直ったバージョン
Debian 13（trixie）	20250419+deb13u1
Debian 12（bookworm）	20250419~deb12u2
Ubuntu 26.10	20260816ubuntu0.26.10.1
Ubuntu 26.04 LTS	20260816ubuntu0.26.04.1
Ubuntu 24.04 LTS	20260816ubuntu0.24.04.1
Ubuntu 22.04 LTS	20260816ubuntu0.22.04.1
Ubuntu 20.04 LTS（ESM）	20240203~20.04.1ubuntu0.1~esm2
Ubuntu 18.04 LTS（ESM）	202402031ubuntu0.18.04.1+esm3
Ubuntu 16.04 LTS（ESM）	202402031~16.04.1~esm3
Ubuntu 14.04 LTS（ESM）	20230311~14.04.1~esm3

Ubuntu 20.04 LTS以前は、Ubuntu Pro（ESM）を使っている場合に更新が届きます。16.04 LTSと14.04 LTSは、Ubuntu ProのLegacy Supportの追加が要ります。

入っているバージョンを確認してください。

dpkg -l 'ca-certificates' | grep ^ii

表のバージョンより古ければ、更新します。Ubuntuは、パッケージをまとめて更新することを勧めています。

sudo apt update && sudo apt upgrade

まとめて更新できないときは、ca-certificates と libnss3 を更新します（Ubuntuは10月22日に、libnss3 の更新も案内に加えています）。

sudo apt update && sudo apt install --only-upgrade ca-certificates 'libnss3*'

Ubuntu 16.04 LTS以降は、自動でセキュリティ更新を入れる機能（unattended-upgrades）がはじめから有効で、24時間ごとに更新が入ります。止めていなければ、すでに入っていることもあります。なお、Ubuntu Desktopのブラウザはsnapで入っていることが多く、ca-certificates ではなくブラウザ自身の仕組みで証明書を確かめます。

Fedora

Fedoraは、ca-certificates-2026.2.92_v9.0.319-1 を、セキュリティ更新（緊急）として出しています。Fedoraの担当者は、この更新で「emSign ECC Root CA - G3」と「AAA Certificate Services」のルート証明書を外すと説明しています。Fedora 43・44・45の分は、そのあと出た ca-certificates-2026.2.92_v9.0.319-2 も含め、10月23日（日本時間）までに通常の配信に入っています。

入っているバージョンを確認してください。

rpm -q ca-certificates

次のコマンドで更新します。

sudo dnf upgrade --refresh ca-certificates

RHEL

Red Hatの告知（RHSB-2026-012）では、まず入っているバージョンを確かめるよう案内しています。

rpm -q ca-certificates

問題の証明書を信頼しないようにする更新は、RHEL 10・9・8向け（RHSA-2026:88455・RHSA-2026:88459・RHSA-2026:88550）、RHEL 7の延長ライフサイクルサポート（ELS）向け（RHSA-2026:88779）、RHEL 6の延長ライフサイクルサポート（ELS）EXTENSION向け（RHSA-2026:90985）が、CVE-2026-114406のページに載っています。次のコマンドで更新します（RHEL 7・6は dnf を yum に置き換えます）。

sudo dnf upgrade ca-certificates

Red Hatは、更新を待つ間の対策として、2つのルート証明書を信頼しないようにする手順を、ナレッジベースで公開しています。トラストストアを手で書き換える作業なので、行うときはRed Hatの手順と注意書きに従ってください。

Dockerなどのコンテナ

コンテナの中の ca-certificates は、ホストのOSを更新しても変わりません。ベースイメージが更新されたら、イメージを取り直して作り直します。自分で作ったイメージも、同じように作り直してください。

自分のサイトの証明書を確かめる（サイトを運営している人）

サイトを運営している人は、自分のサイトの証明書が「emSign ECC Root CA - G3」につながっていないか確認してください。MozillaとChromeはこのルート証明書を信頼する一覧から外していて、Chromeでの取り外しを、Chromeのルート証明書の一覧を使うすべての端末向けに、米国太平洋時間の10月27日（火）朝に出す見込みだとGoogleは発表しています。このルートにつながる証明書を使っているサイトは、Chromeではつながらなくなるので、すぐにほかの認証局の証明書に入れ替えるよう、Googleは求めています。

次のコマンドで、サイトが送ってくる証明書と、その発行元（i: の行）が表示されます（www.example.com は自分のサイトに置き換えます）。

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | grep -E '^ *[0-9]+ s:|^ +i:'

どの行にも emSign や eMudhra が出てこなければ、今回の件での作業はありません。出てきたときは、証明書を買った会社に相談します。eMudhraは10月28日、このルートのもとで出した証明書は約3万800枚で、その利用者は別のルート（emSign Root CA - G1）からの発行を使い始めているとしています。ただし、G1からの発行も移行のあいだだけで、移行が終わればやめるとしています。

よくある質問

証明書の確認を止めれば、とりあえずつながりますか

つながりますが、しないでください。確認を止めると、今回のような偽の証明書もそれ以外の証明書もすべて受け入れてしまい、通信の間に入るなりすましを防げなくなります。

Goで作ったツールやサービスはどうなりますか

Goは1.27.3と1.26.10で、この中間証明書を含む証明書チェーンをはじくようにしました。Goのチームは、すぐにこのバージョンに上げるよう強く勧めています。確かめ方と手順は、Go 1.27.3・1.26.10の緊急更新の記事を見てください。

ほかの認証局にも同じ問題がありますか

Mozillaは、dev-security-policyで、この問題はほかの認証局には及ばないと考えているとしています。Googleも、Chromeのルート証明書の一覧に入っているほかの鍵に、同じ弱さを持つものはなかったとしています。

参考リンク

• Bug 2083449 – eMudhra: Private key compromise of Intermediate Certificates（Mozilla Bugzilla）
• Compromised eMudhra Intermediate Certificates（dev-security-policy）
• Protecting Firefox users following the compromise of eMudhra intermediate certificates（Mozilla Security Blog）
• MFSA 2026-112（Mozilla）
• Bug 2084101 – Remove eMudhra emSign Root CA – G3 from NSS（Mozilla Bugzilla）
• Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates（Google）
• eMudhra Statement on Recent Certificate Security Incident（eMudhra）
• DSA-6572-1 ca-certificates（Debian）
• DLA-4845-1 ca-certificates（Debian）
• ca-certificates（Debian Security Tracker）
• USN-8944-1・USN-8944-2・USN-8947-1（Ubuntu）
• eMudhra CA compromise fixes available（Ubuntu）
• ca-certificates の更新（Fedora Bodhi）
• Bug 2556376 – Update to mitigate current issues with eMudhra（Fedora／Red Hat Bugzilla）
• RHSB-2026-012 Certificate compromise – eMudhra（Red Hat）
• CVE-2026-114406（Red Hat）
• RHSA-2026:88779 ca-certificates security update（Red Hat Enterprise Linux 7 Extended Lifecycle Support）

この記事は2026年10月22日時点の情報です（Fedoraの部分は10月27日、Chrome・Android・RHEL・Debian・Ubuntu・eMudhraの部分は11月4日10時20分（日本時間）時点）。