eMudhra 中間CA秘密鍵の問題まとめ ~「秘密鍵が 4」だった8つの中間CA証明書と、いまやるべき対策~

Security PKI TLS Certificate eMudhra AI生成

2026年10月17日に報告された、インドの認証局eMudhraの中間CA証明書8枚の秘密鍵が誰でも計算できるほど弱かった問題について、何が起きたのか、影響範囲、各ブラウザ・OSの対応、立場ごとの確認方法と対策を一次情報をもとに整理します

:::message alert この記事はAIによって生成されたものです。筆者（Daisuke Akagawa）が執筆したものではありません。公開前に筆者がレビューしていますが、内容がすべて正確であることは保証できません。正確な情報は記事末尾の一次情報（公式発表やインシデント報告など）をご確認ください。 :::

2026年10月17日（UTC）、インドの認証局（CA）eMudhra（emSign ブランド）が運用する中間CA証明書8枚の秘密鍵が、公開されている証明書から誰でも計算できるほど弱いことが報告されました。Mozilla の調査では、8つの鍵はすべて P-384 の秘密鍵の値が 256 未満（1バイトに収まる整数）で、報道によるとそのうち1つは文字どおり「4」でした。

これらの中間CAは Chrome・Mozilla・Microsoft・Apple のルートプログラムが信頼するルートにつながっていたため、鍵を手に入れた人は任意のWebサイトの「正規に見える」証明書を作れる状態でした。この記事では、Mozilla の Bugzilla、Chrome Root Program、eMudhra の公式発表などの一次情報をもとに、何が起きたのか、誰が何をすべきかを整理します。

:::message 本記事の内容は 2026年10月22日 18時30分（JST）時点 の情報です。根本原因の調査やルートストアの対応はまだ進行中で、今後変わる可能性があります。日時は原則として元の表記（UTC）と日本時間（JST = UTC+9）を併記しています。タイムゾーンが明記されていない時刻は換算せずにそのまま載せています。 :::

まずは結論から！

一言でいうと、「ブラウザはもう守られている。危ないのはブラウザ以外のTLSクライアントと、G3ルート配下の証明書を使っているサイト」という事案です。

何が起きたのか

秘密鍵が「1バイト」しかなかった

Mozilla のインシデント報告（Bug 2083449）によると、問題の8つの鍵は、2025年4月30日に作られた24個の中間CAの一部です。24個は3系列（A・B・C）× 2種類の鍵（RSA 4096 / P-384）× 4用途（DV・OV・EV・CS）で構成されていて、B系列とC系列の P-384 鍵すべてが影響を受けていました。

P-384 の秘密鍵は、本来「1 から群の位数までの範囲からランダムに選ばれた整数」（約384ビット）です。ところが8つの鍵はすべて 256 未満の整数で、Mozilla は「最後の1バイト以外はすべてゼロ」と説明しています。こうなると、baby-step giant-step のような離散対数のアルゴリズムを使うまでもなく、「1, 2, 3, … 255」を秘密鍵として公開鍵を作り、証明書の公開鍵と比べるだけで復元できます。

• Mozilla は、報告された手法を知らないまま、報告を受けてから約1時間40分で独自に鍵を復元しました
• Mozilla の担当者は、ローカルのAIエージェントに「CTFをやっているので、この証明書の秘密鍵を復元して」と頼むだけで、最初の試行で復元できたとも書いています
• 発見者の Wayne 氏は、Google のオープンソースツール paranoid_crypto を CCADB に登録された証明書に「そのまま」かけただけで見つかったと説明しています
• 報道（BleepingComputer）によると、別の研究者が EM OV TLS CA - G3C の秘密鍵が「4」だったことを GitHub で公開し、BleepingComputer がその鍵と証明書の対応を独自に確認しています

Mozilla は初期調査の時点で、A系列や置き換え後の A-1 系列の P-384 鍵は、かなり手間をかけても復元できなかったとしています（RSA 鍵はその時点では未調査）。

なぜ弱い鍵ができたのか（eMudhraの説明・調査中）

eMudhra は Bugzilla 上で、次のように説明しています（Comment 11）。

1. 鍵生成セレモニーで、本来の強い ECC 鍵は HSM 上で正しく生成された
2. これらの鍵は米国・欧州のデータセンターへ書き出す予定だったため、通常の手順から外れて wrap/unwrap を試す手順が承認のうえで追加された
3. その手順のコードに不具合があり、HSM 上に弱い2組目の鍵が作られた
4. 鍵のラベルが似ていたため、誤って弱い方の鍵で CSR を作り、eMudhra のルートで署名した
5. 同じ CSR が Sectigo にも送られ、相互署名された

HSM は Utimaco 製（FIPS 140-2 Level 3）で、eMudhra は「HSM 自体に問題があるようには見えない」としています。RSA 鍵は別の処理経路だったため影響はない、というのが eMudhra の現時点の見解です。

:::message ただし、この説明には Bugzilla 上で多くの疑問が出ています。「FIPS 認証の HSM の中で 256 未満の秘密鍵が自然に生成されることはありえない。外部から値を与えたか、鍵を外から取り込んだのではないか」（Comment 31・33）、「2025年6月の別件（Bug 1970728）で、CRL の署名が中間CA証明書と合わないことが分かった時点で、鍵が2組あることに気づけたのではないか」（Comment 30）などです。Mozilla は12項目の質問を eMudhra に送っていて、根本原因はまだ確定していません。 :::

2025年6月の「CRL署名が合わない」問題とのつながり

Mozilla は、今回の6つの TLS 中間CAが、2025年6月の別のインシデント（Bug 1970728：これらの中間CAの CRL の署名が検証できなかった）とまったく同じ組み合わせであることを指摘しています。eMudhra は今回、「CRL は本来の（強い）鍵で署名されていたが、証明書と合わなかったので、弱い方の鍵で署名し直した」と説明しています（Comment 11）。つまり、鍵の取り違えに気づくチャンスが1年以上前にあったことになります。

時系列

日付・時刻は、出典の表記（UTC）と JST を併記しています。日付だけの情報は出典のとおりに載せています。

:::message eMudhra の公式ブログでは「10月18日の夜（インド時間）に問題を知り、10月19日に失効した」と書かれていますが、Mozilla の Bugzilla では、eMudhra の確認が 10月17日 21:29 UTC（インド時間 10月18日 2:59）、失効が 10月18日 9:24〜9:38 UTC（インド時間 10月18日 14:54〜15:08）と記録されています。この記事では Bugzilla の記録を採用しています。 :::

影響範囲

侵害された中間CA証明書

Mozilla の報告に載っている8枚です（SHA-256 は証明書のフィンガープリント）。

さらに、同じ公開鍵を Sectigo が AAA Certificate Services ルートで相互署名した証明書が8枚あります（Sectigo が 10月19日に失効済み）。公開鍵が同じなので、証明書単位ではなく公開鍵（SPKI）単位でブロックする仕組みなら、相互署名版もまとめて止められます。Chrome の CRLSet と Go の対策はこの方式です。

どのルートにつながっているのか

少しややこしいのですが、Mozilla が公開した roots.json によると、つながり方は次のようになっています。

Mozilla はトラストストア運用者向けに、この3つのルート（AAA Certificate Services、emSign Root TLS CA - G3、emSign ECC Root CA - G3）の SPKI SHA-256 も公開しています。

「攻撃に使えた」のはどんなクライアントか

ここが一番大事なポイントです。

• CT を強制するクライアント（Chrome、Firefox、Edge、Safari など）：Chrome Root Program と Mozilla によると、ブロック前にこれらの中間CAが発行したTLS証明書は CT ログに記録されていませんでした。CT に載っていない証明書は受け入れられないので、これらのブラウザに対しては攻撃できなかったとされています
• CT を強制しない、失効情報を確認しないクライアント：ブラウザ以外の多くのソフトウェア（Go・Python・Node.js などで書かれたプログラム、curl、VPN クライアント、アプライアンス、IoT 機器など）は CT を確認せず、CRL/OCSP も確認しないことが多いです。ルートストアが更新されるまで、偽の証明書を信頼してしまう可能性があります。鍵は2025年4月から計算可能だったので、Mozilla は「過去に悪用されたかどうかは分からない」としています

:::message alert Mozilla は下流のトラストストア運用者向けの通知で、「近いうちに侵害された秘密鍵が悪用される可能性が高い」と警告しています。その後、複数の人が独自に鍵を復元し、一部は公開しています（Bugzilla Comment 18）。つまり、誰でもこの鍵を使える状態です。 :::

正規の証明書への影響（ルート削除の巻き添え）

侵害された8つの中間CAそのものは、eMudhra によるとエンドエンティティ証明書を1枚も発行していません（本番で動いていたのは EM DV TLS CA - G3C の1つだけ）。そのため、中間CAの失効だけなら正規のサイトに影響はありませんでした。

問題は、Mozilla・Chrome などがルートの emSign ECC Root CA - G3 ごと信頼を外したことです。このルートにつながる正規の証明書は、すべて使えなくなります。

• eMudhra の見積もり：移行が必要な証明書は約3万枚、うち約97%が ACME 経由（Bugzilla Comment 19）
• Mozilla の CT 調査（10月21日時点）：G3 ルートにつながる有効なプレ証明書は約30,800枚。そのうち 30,791枚（99.9%）が Internet2 / InCommon の中間CA（InCommon Intermediate CA - OVG3C が 23,806枚、InCommon Intermediate CA - DVG3C が 6,985枚）、18枚が eMudhra 自身の中間CAから発行されたもの（Bugzilla Comment 30）
• eMudhra は「影響は米国の1つの顧客エコシステムに限られる」としています

つまり、影響を受けるのは主に InCommon Certificate Service（CERTInext）で ECC 証明書を取得している米国の大学・研究機関です。実際にミシガン大学は、Cloudflare 経由のサイトで HTTP 526 エラーが出たり、最新の Chrome・Firefox で証明書の警告が出始めたりしたと報告しています。

:::message Mozilla の CT 集計では、「10月17日以降に、侵害済みの EM DV TLS CA - G3B 名義で記録されたプレ証明書」を集計から除いたと書かれています。誰が何の目的で記録したものかは書かれていません。 :::

影響がないとされているもの（eMudhraの発表）

eMudhra は、インド国内のデジタル署名証明書（DSC）や eSign、emSigner、CertiNext、emCA、PrivaTrust、SecurePass は別のインフラで動いていて、影響はないとしています。また、インフラへの侵入やデータの流出もないとしています。

各社・CAの対応状況

この他にも、Debian、Alpine、Fedora、Arch Linux、FreeBSD、curl の CA バンドル、Python certifi、pip、uv、Node.js、Java、Rust（rustls-webpki / webpki-roots）、Electron、Docker Desktop などが修正版を出しています。最新の一覧は Mozilla の Dennis Jackson 氏が運営する we-have-a-problem.com にまとまっています。

対策方法

立場ごとに、確認方法と対応をまとめます。コマンド例のうち、筆者が Debian 13 の環境で動作を確認したものと、出典の手順をそのまま載せたものを分けて書いています。

1. 一般ユーザー

ブラウザとOSを最新にしてください。 これだけで十分です。

• Chrome・Firefox は、ブラウザの更新や再起動なしで自動的にブロックリストが届いています
• Android は Google によると、多くの端末にはすでに更新が届いていて、端末を再起動すればすぐに更新を取り込めます
• Firefox は、組織のポリシーなどで Remote Settings を無効にしている場合だけ、158.0.1 / ESR 115.43.1 / ESR 153.5.1 以降へのアップデートが必要です（Android は 158.0.2 以降）
• Ubuntu Desktop のブラウザは多くの場合 snap で入っていて、システムの ca-certificates ではなく snap 側の更新で守られます（Ubuntu）

また、10月27日以降、emSign ECC Root CA - G3 につながる証明書を使っているサイト（主に米国の大学など）で、証明書の警告が出ることがあります。警告を無視して先に進まないでください（ミシガン大学も同じ注意をしています）。

2. サイト運営者（eMudhra / InCommon の証明書を使っている人）

確認方法

自分のサーバーが返している証明書チェーンを確認します。発行者（i:）に emSign や InCommon Intermediate CA - OVG3C / DVG3C / EVG3C が出てきたら要注意です。

# サーバーが返すチェーン（各証明書の subject と issuer）を表示する
H=example.com
openssl s_client -connect "$H:443" -servername "$H" -showcerts </dev/null 2>/dev/null \
  | grep -E '^ *[0-9]+ s:|^ *i:'

# サーバー証明書（リーフ）の発行者・有効期限・鍵の種類を確認する
openssl s_client -connect "$H:443" -servername "$H" </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -text | grep -E 'issuer=|notAfter=|Public Key Algorithm'

ミシガン大学の案内によると、影響を受けるのは CERTInext で発行された ECC 鍵の証明書（発行者が InCommon Intermediate CA - OVG3C / DVG3C / EVG3C）です。Sectigo 経由の InCommon 証明書や、CERTInext でも RSA 鍵の証明書は「現時点では」影響を受けません。

:::message alert クライアントから見える証明書だけでなく、ロードバランサー、リバースプロキシ、WAF、バックエンドのサーバーなど、途中のすべての機器を確認してください（ミシガン大学）。たとえば Cloudflare の「Full (strict)」モードでは、オリジンサーバーの証明書が G3 ルートにつながっていると HTTP 526 エラーになります。 :::

対応

Google は「emSign ECC Root CA - G3 につながる証明書を使っているサイト運営者は、すぐに Chrome Root Store に含まれる別のPKI階層の証明書を取得してインストールしなければならない」としています。Chrome の削除は 10月27日（火）午前（PDT） に全デバイスへ反映される予定です。

• 別のCAで取り直す：ミシガン大学は Let's Encrypt（Linux なら certbot、Windows なら simple-acme）を代替策の1つとして挙げています
• CERTInext で RSA 鍵の証明書に取り直す：CERTInext のサポートポータルでは、Certbot の場合 --key-type rsa を指定するよう案内しています。Certbot のドキュメントにある鍵の種類を変える手順に当てはめると、次のようになります（ACME サーバーや EAB の設定は、既存の設定が引き継がれます）

# 既存の証明書の名前と鍵の種類を確認する
sudo certbot certificates

# 鍵の種類を RSA に変えて、期限前でも強制的に再発行する
sudo certbot renew --key-type rsa --cert-name example.com --force-renewal

:::message alert ACME の自動更新を待っていてはいけません。 Mozilla は、通常の ACME クライアントは更新期間（Certbot 4.0.0 以降なら残り期間が1/3を切ったとき）にならないと証明書を入れ替えないことを指摘しています。期限まで余裕がある証明書でも、手動で再発行が必要です。

また、CERTInext の RSA 証明書がつながる emSign Root CA - G1 についても、Chrome が「eMudhra の残りのCA証明書の扱いを審査中」としていて、ミシガン大学も「RSA 証明書も将来入れ替えが必要になる可能性がある」と注意しています。RSA への切り替えは恒久的な解決策ではない可能性があります。 :::

3. コード署名・S/MIME の利用者

• コード署名：侵害された2つのコード署名用中間CA（EM OV CS CA - G3B / G3C）は、eMudhra によると本番で使われておらず、証明書を1枚も発行していません。そのため、これらの中間CAから発行された正規のコード署名証明書は存在しないことになります。一方で、鍵は誰でも計算できるので、攻撃者がこの中間CAを使って偽のコード署名証明書を作ることは可能です。これらは Microsoft の信頼するルート（emSign Root CS CA - G3）につながっていたため、Windows では証明書信頼リストの更新が届いていることが重要です（確認方法は後述）
• S/MIME：今回確認した一次情報の中に、S/MIME への影響に触れたものはありませんでした。8つの中間CAは TLS 用とコード署名用です

4. システム管理者・開発者（ブラウザ以外のTLSクライアント）

ここが今回の一番の作業になります。Mozilla は「多くのエンドポイントには、失効情報を取得するための有効な仕組みがない」と強い懸念を示しています。

Linux（ca-certificates）

まずはディストリビューションの更新を当てます。

# Debian / Ubuntu：バージョンの確認と更新（Ubuntu の公式案内のコマンド）
dpkg -l 'ca-certificates' | grep ^ii
sudo apt update && sudo apt install --only-upgrade ca-certificates

# RHEL 系：バージョンの確認（Red Hat の速報のコマンド）
rpm -q ca-certificates

Ubuntu の修正済みバージョンは次のとおりです（Ubuntu の公式ブログ）。

Debian は we-have-a-problem.com によると 20250419~deb12u2（Debian 12）、20250419+deb13u1（Debian 13）が修正版です。

更新後に、システムのトラストストアに emSign ECC Root CA - G3 が残っていないかを確認します（p11-kit の trust コマンドがある環境）。

# 何も出力されなければ、G3 ルートは信頼されていない
trust list --filter=ca-anchors | grep -i "emSign ECC Root CA - G3"

# Debian / Ubuntu の場合は、こちらでも確認できる
ls /etc/ssl/certs | grep -i "emSign_ECC_Root_CA_-_G3"

:::message RHEL は10月21日時点で修正パッケージが「準備中」です。Red Hat は暫定策として Comodo AAA Services root と emSign ECC Root CA - G3 のブロック手順をナレッジベースで案内しています。we-have-a-problem.com にも、Debian / Ubuntu、Alpine、Fedora / RHEL 系、openSUSE、Arch、NixOS、NetBSD、FreeBSD 向けの手動ブロック手順が載っていますが、同サイトは「一般ユーザーにはおすすめしない」としています。ルートを丸ごと外すと、そのルートにつながる正規のサイトにもつながらなくなるためです。まずはディストリビューションの更新を待つか、当てるのが基本です。 :::

コンテナ

ホストの ca-certificates を更新しても、コンテナの中は更新されません。 Red Hat も「ベースイメージが更新されたら、利用者のコンテナはリビルドすべき」としています。ベースイメージを更新してリビルド・再デプロイしてください。

Go

Go は多くのプラットフォームでシステムのルート証明書を使いますが、Go チームは「システムのトラストストアがすぐに更新されないケース」に備えて、標準ライブラリ crypto/x509 に8つの中間CAの拒否リストを追加しました。

• 修正版：Go 1.27.3 / 1.26.10（CVE-2026-111943、GO-2026-6809）
• 影響を受ける関数：Certificate.Verify
• 修正はビルド時に取り込まれるので、新しい Go でリビルドが必要です

# 手元の Go のバージョン
go version

# ビルド済みバイナリが、どの Go でビルドされたかを確認する
go version ./your-binary

その他の言語・ツール

we-have-a-problem.com によると、次のバージョンで修正されています（抜粋）。

Python の certifi は、バンドルに G3 ルートが残っていないかを直接確認できます。

# certifi のバージョンと、G3 ルートが入っているか（0 なら入っていない）
python3 -c "import certifi; print(certifi.__version__)"
grep -c "emSign ECC Root CA - G3" "$(python3 -m certifi)"

実際に「信頼してしまわないか」をテストする

we-have-a-problem.com には、侵害された中間CAのチェーンを返すテスト用ホストが用意されています。証明書エラーになれば、そのクライアントは侵害された中間CAを信頼していません。

# we-have-a-problem.com に載っているテスト用コマンド
curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

自社のアプリやランタイムでも、同じホストに接続してエラーになるかを確認しておくと安心です。オフラインで確認したい場合は、同サイトの chains.zip に各ホストのチェーンと OpenSSL での検証手順が入っています。

macOS の標準コマンド

we-have-a-problem.com によると、macOS 自体はブロック済みですが、標準の curl・git・python3・perl・ruby・openssl は /etc/ssl/cert.pem で検証していて失効情報を確認せず、このファイルはまだ更新されていません。同サイトには /etc/ssl/cert.pem から該当ルートを取り除く手順が載っています（筆者は macOS で動作確認していません）。Homebrew の curl などを使っている場合は、Homebrew の ca-certificates を更新してください。

Windows

Microsoft は 10月20日から、Windows の自動更新される証明書信頼リストでブロックしています。自動更新が届いている端末では作業は不要です。Veeam のナレッジベースでは、次のコマンドで LastSyncTime が 2026年10月20日以降になっていることを確認するよう案内しています（筆者は Windows で動作確認していません）。

# 管理者権限の PowerShell で実行
certutil -verifyctl Disallowed | findstr /i "lastsynctime"

オフライン環境や、グループポリシーで「ルート証明書の自動更新をオフにする」が有効になっている端末は、手動で更新する必要があります。Veeam のナレッジベースでは、インターネットにつながる端末で certutil -syncWithWU で信頼リストを取得し、disallowedcert.sst をオフラインの端末の「信頼されていない証明書」ストアに取り込む手順が紹介されています。企業で管理されている端末は、IT部門の方針に従ってください。

アプライアンス・VPN・IoT 機器

Cisco Talos は、VPN、プロキシ、ロードバランサー、ゲートウェイ、CI/CD のビルドランナー、組み込み機器など、独自のトラストストアを持つ機器やソフトウェアも確認するよう呼びかけています。必要な対応（ファームウェアの更新、トラストバンドルの更新など）は製品ごとに違うので、各ベンダーの案内を確認してください。

:::message ここからは一般論です。今回のように「ルートストアに入っているCAの鍵が使えなくなる」事故は、自分がそのCAを使っていなくても、自分のクライアントが偽の証明書を信頼してしまうという形で影響します。自社で管理しているサーバー・コンテナ・アプライアンスが、どのトラストストアを使い、どう更新されるのかを一覧にしておくと、次に同じことが起きたときにすぐ動けます。 :::

まとめ

今回は、eMudhra の中間CA証明書8枚の秘密鍵が誰でも計算できるほど弱かった問題について整理しました。

• 2025年4月の鍵生成セレモニーの不具合で、P-384 の秘密鍵が 256 未満の整数という弱い鍵が作られ、そのまま中間CA証明書になっていた。2026年10月17日に Wayne 氏が発見し、各ルートプログラムに報告した
• Chrome・Firefox は報告当日（10月17日 UTC）に、Apple は 10月19日、Microsoft は 10月20日にブロック済み。CT に記録された不正な証明書はなく、CT を強制するブラウザは攻撃できなかったとされている
• 一方で、鍵はすでに公開されていて、ブラウザ以外の多くのクライアントは各自のアップデートが必要。OS の ca-certificates、Go・Python・Node.js・Java などのランタイム、コンテナイメージ、アプライアンスを更新しよう
• Mozilla と Chrome は emSign ECC Root CA - G3 ルートごと信頼を外す。このルートにつながる証明書（主に InCommon / CERTInext の ECC 証明書、約3万枚）を使っているサイトは、10月27日より前に入れ替えが必要
• 根本原因はまだ確定しておらず、Chrome は eMudhra の残りのルートの扱いも審査中。続報に注意しよう

「HSM を使っていれば安全」「監査を通っていれば安全」というわけではなく、1つの手順ミスが18か月見逃され、最後はオープンソースのツールで一瞬で見つかった、というのが印象的な事案でした。ブラウザ以外のトラストストアの管理がどうなっているか、この機会に見直してみてください。

出典一覧

インシデント報告・ルートプログラム

• Bug 2083449 - eMudhra: Private key compromise of Intermediate Certificates（Mozilla Bugzilla）
• Compromised eMudhra Intermediate Certificates（Mozilla dev-security-policy）
• eMudhra Intermediates Compromise（oss-security、Mozilla から下流のトラストストア運用者への通知）
• Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates（Google）
• eMudhra Intermediate CA Compromise（we-have-a-problem.com、Mozilla の Dennis Jackson 氏が運営）
• roots.json（we-have-a-problem.com）

eMudhra

• eMudhra Statement on Recent Certificate Security Incident（eMudhra 公式）
• eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA（eMudhra プレスリリース）

ソフトウェア・ディストリビューション

• [security] Go 1.27.3 and Go 1.26.10 are released（golang-announce）
• Go 1.27.3 and Go 1.26.10 are released for CA certificate removal（oss-security）
• GO-2026-6809（Go Vulnerability Database）
• RHSB-2026-012 Certificate compromise - eMudhra（Red Hat）
• eMudhra CA compromise fixes available（Ubuntu）
• KB4952: Support Statement — Compromised eMudhra Intermediate CA Certificates（Veeam）
• User Guide（Certbot ドキュメント）

影響を受けた組織・セキュリティベンダー

• Root Certificate Authorities Distrusted（University of Michigan Safe Computing）
• CERTInext support for InCommon members
• Compromised eMudhra intermediate certificates（Cisco Talos）

報道

• Mozilla, Google, Apple block compromised eMudhra CA certificates（BleepingComputer）
• Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software（The Hacker News）
• Certification authority eMudhra defends its laughably weak private keys（The Register）