ChromeとFirefoxは、2026年10月18日（日本時間）の朝までに、秘密鍵がもれたeMudhraの中間CA証明書をはじくよう対応していて、この2つを使っている人は、特別な操作なしで守られています。LinuxのサーバーやPC、WSL、Dockerイメージを使っている人は、ca-certificates を今回直ったバージョンに更新し、そのバージョンを確かめてください。
結論：ChromeとFirefoxは対応済み、Linuxは ca-certificates を更新する
- 何が起きたか：認証局eMudhraの中間CA証明書8枚で、鍵を作るときの乱数が足りず、第三者が秘密鍵を割り出せる状態でした。悪用されると、どのサイトにもなりすませる証明書を作れてしまいます
- Chrome・Firefox：10月18日（日本時間）の朝までに、更新や再起動なしではじくようになっています
- Android：Google Play開発者サービスを通じて同じ対応が届いています。すぐに反映したいときは端末を再起動します
- Linux：Debian・Ubuntu・Fedoraは、もとになったルート証明書を外した
ca-certificatesを出しています。Red Hat Enterprise Linux（RHEL）は、更新パッケージを出しだい公表するとしています - サイトを運営している人：自分のサイトの証明書が「
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
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を確かめるクライアントに対して偽の証明書は使えなかったとしています。
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
直った 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 だけを更新します。
sudo apt update && sudo apt install --only-upgrade ca-certificatesUbuntu 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 44の分は、10月22日1時43分（日本時間）に通常の配信（stable）に入りました。Fedora 43と45の分は、10月22日6時40分（日本時間）時点で、テスト用の配信（updates-testing）から通常の配信に移す手続き中でした。
入っているバージョンを確かめます。
rpm -q ca-certificates通常の配信に届いたら、次のコマンドで更新します。
sudo dnf upgrade --refresh ca-certificatesRHEL
Red Hatの告知（RHSB-2026-012）では、まず入っているバージョンを確かめるよう案内しています。
rpm -q ca-certificatesもとのルート証明書を外した更新パッケージは、RHSB-2026-012の「Updates for Affected Products」の欄で公表されます。10月22日6時40分（日本時間）時点では、まだ載っていませんでした。載ったら、RHEL 8以降は次のコマンドで更新します（RHEL 7とRHEL 6は dnf を yum に置き換えます）。
sudo dnf upgrade ca-certificatesRed Hatは、更新を待つ間の対策として、2つのルート証明書を信頼しないようにする手順を、ナレッジベースで公開しています。トラストストアを手で書き換える作業なので、行うときはRed Hatの手順と注意書きに従ってください。
Dockerなどのコンテナ
コンテナの中の ca-certificates は、ホストのOSを更新しても変わりません。ベースイメージが更新されたら、イメージを取り直して作り直します。自分で作ったイメージも、同じように作り直してください。
自分のサイトの証明書を確かめる（サイトを運営している人）
サイトを運営している人は、自分のサイトの証明書が「emSign ECC Root CA - G3」につながっていないかも確かめます。MozillaとChromeはこのルート証明書を信頼する一覧から外していて、Googleによると、Chromeでの取り外しはすべての端末向けに、米国太平洋時間の10月27日（火）朝に出る予定です。このルートにつながる証明書を使っているサイトは、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は、このルートにつながる証明書は、はじめの見積もりで約3万枚あり、利用者を別のルート（emSign Root CA - G1）につながる中間CAに移すとしています。
よくある質問
証明書の確認を止めれば、とりあえずつながりますか
つながりますが、しないでください。確認を止めると、今回のような偽の証明書もそれ以外の証明書もすべて受け入れてしまい、通信の間に入るなりすましを防げなくなります。
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（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）
確認日：2026年10月22日
コメント