証明書の信頼の一覧の地図 eMudhraの件で見るブラウザ・OS・言語の更新

インドの認証局eMudhraの中間証明書8件で、秘密鍵の作り方に誤りがあり、だれでも鍵を取り出せる状態でした。10月17日の報告から1週間で、ブラウザ、OS、言語、製品の各社が、それぞれの「信頼の一覧」(どの認証局の証明書を正しいとみなすかの一覧)を直しました。

この件で分かったのは、信頼の一覧が1か所ではないことです。ブラウザが守られても、サーバーやアプリはそれぞれの一覧を持っていて、別に直す必要があります。この記事は、一覧の置き場所と直し方を、2枚の図にまとめました。事故そのものの詳しい経過は、eMudhra、中間CAの鍵が破られSSL/TLS事業から撤退 証明書の差し替えと一覧の更新をにあります。

信頼の一覧は、4つの場所にある

Mozillaは、信頼の一覧を配る各社に向けて、失効の情報を必ず確かめ、確かめられなければ接続を断る仕組みなら対応は要らないと説明しています。逆にいえば、失効を確かめない仕組みは、一覧を直すまで守られません。FreeBSDは、OpenSSLは初期の設定では失効を確かめないとしています。

報告から1週間の動きと、守られ方の4つの型

守られ方は、4つの型に分けられます(当社の整理)。

なぜ、ブラウザ以外は遅れるのか

ブラウザは、遮断の一覧を自分で配る仕組み(CRLSetやOneCRL)を持っていて、利用者が何もしなくても数時間で守られます。これに対して、サーバーのOSや言語は、証明書の一覧をファイルとして持ち、更新を入れたときに入れ替わります。さらに、Goで作ったツールのように、一覧をプログラムの中に組み込んでいるものは、作り直すまで古い一覧のままです。

社内のシステムは、ブラウザよりも、サーバーの間の通信(APIの呼び出し、バッチ、監視の道具)の方が多くあります。そうした通信は、ブラウザの更新では守られません。今回の件は、どの仕組みがどの一覧を使っているかを知っておく機会になります(当社の見立て)。

影響する会社・しない会社

• 影響する: サーバーやコンテナで、Python・Java・Go・Node.jsのアプリを動かしている会社。言語ごとの一覧の更新や作り直しが要ります
• 影響する: emSignのSSL/TLSの証明書を自社のサイトやAPIで使っている会社。10月27日(米国時間)以降、Chromeからつながらなくなる恐れがあり、差し替えが要ります
• 影響する: 取引先のサイトやAPIにつなぐ会社。相手がemSignの証明書を使っていると、接続が止まることがあります
• 影響が小さい: 社員がブラウザだけでWebのサービスを使う会社。ChromeとFirefoxは自動で守られています

情シスが今日やること

1. サーバーのOSの更新を入れます。 Debianはca-certificatesの更新、FreeBSDはSA-26:73の更新を入れ、OpenSSLを使う常駐のプログラムを再起動します。
2. 言語ごとの一覧を確かめます。 Pythonはすべての仮想環境でpipとcertifiを上げ、単体で入れたJavaは更新するか、blocked.certsで8件を止めます。Node.jsは22.23.4・24.22.1・26.12.1へ上げます。
3. Goで作ったツールを作り直します。 社内で作ったGoのツールは1.27.3か1.26.10で作り直し、買った製品はメーカーに更新の予定を聞きます。
4. emSignの証明書を探します。 自社のサイト・API・VPNで使っていれば、10月27日より前に、ほかの認証局の証明書へ差し替える日を決めます。
5. 接続の切り分けの手順に入れます。 取引先のAPIなどにつながらなくなったら、相手の証明書がemSignでないか、Debianの更新で外れたAAA Certificate Servicesの古い連なりでないかを確かめる、と手順に書いておきます。