SSL証明書は期限内でも
使えなくなる？eMudhra問題で企業が確認する12項目

「SSL証明書は自動更新にしているから、大丈夫」。そう考えていても、ブラウザに突然警告が出て、会社のホームページやネットショップを開けなくなることがあります。

証明書には、有効期限のほかに「発行元が信頼されているか」という条件があるためです。2026年10月に発覚した認証局eMudhraの問題は、その確認が必要になる事例です。

レイズでは、自社サイト2件の証明書調査、実験用HTTPSサイトでの接続検証、公開テストサイトへの接続を行いました。この記事では、その結果をもとに、企業のWeb担当者・経営者が確認することを12項目にまとめます。

まず行う3つのこと

1. 制作会社・保守会社に、証明書の発行元と認証経路を確認してもらう。
2. 対象なら、証明書の切り替え方法と対応日を決める。
3. 切り替え後は、フォーム・ログイン・注文・API連携まで確認する。

情報確認・検証日：2026年10月26日。本文では一般的な呼び方の「SSL証明書」を使いますが、対象の通信方式はTLSです。

eMudhra問題で自社サイトに何が起こるのか

認証局は、Webサイトなどの証明書を発行する組織です。今回、eMudhraの8つの中間認証局で、秘密鍵を第三者が推測できる重大な問題が見つかりました。うち6つはWebサイトなどのTLS用、2つはソフトウェアのコード署名用です。暗号方式そのものではなく、鍵の生成に問題がありました。CERT-Inの注意喚起

ブラウザなどは、サイトの証明書から中間認証局をたどり、信頼するルート認証局へつながるかを確認します。このつながりが「証明書チェーン」です。

今回の対応は、次の2つに分けて理解する必要があります。

表は横にスクロールして確認できます。

Googleは10月17日に問題の中間認証局の鍵をブロックしました。さらに、G3ルートをChrome Root Storeから外す変更を、10月27日午前・米国太平洋夏時間に広く展開する予定です。日本時間の27日午前ではありません。Googleの公式発表

Appleも、問題の中間認証局を10月19日から、G3ルートを23日からブロックしたと説明しています。接続に使うソフトによって対応時期や検証方法が異なるため、Chromeの予定日まで待てばよいとは限りません。Appleの公式説明

eMudhraという名前だけで一律に交換を決めず、自社の証明書がどの経路につながるかを確認してください。 別の認証局を経由する「クロス署名」の経路もあるため、ルート名だけの確認では見落とす場合があります。

なお、証明書が拒否されること自体は、サイトが侵入された証拠ではありません。eMudhraは10月26日の声明で、調査時点では問題の中間認証局から公開信頼の末端証明書を発行しておらず、インフラや顧客データの侵害も確認していないと説明しています。eMudhraの声明

レイズの検証で確認した3つのこと

自社サイト2件は対象の認証経路を使っていなかった

公開HTTPS通信とChromeが構築した認証経路を確認した結果、次の2サイトはいずれもGlobalSign系統でした。

表は横にスクロールして確認できます。

これは10月26日の2ホストの公開HTTPS接続についての結果です。別のサブドメインやメールサーバー、外部APIまで調べた結果ではありません。

有効期限内でも、信頼設定を変えると接続できなくなった

Mac内に実験専用の認証局A・BとHTTPSサイトを用意し、同じURL・同じページで比較しました。

1. Aの証明書を使い、接続側がAとBを信頼する：3回とも接続成功。
2. サーバーの証明書は変えず、接続側がBだけを信頼する：3回とも証明書エラー。
3. サーバーをB系統の証明書へ交換する：3回とも接続成功。

2の時点でも証明書は有効期限内で、サーバーも動いていました。期限が残っていても、発行元への信頼を失えば接続は止まることを確認できました。実験用の信頼設定だけを変更した仕組みの検証で、eMudhraの鍵や攻撃を再現したものではありません。

同じMacでも、curlとChromeで結果が異なった

問題の中間認証局につながる公開テストサイト2経路へ接続したところ、Mac標準のcurlでは両方とも証明書検証を通過し、HTTP 200が返りました。証明書検証を無効にするオプションは使っていません。

一方、失効情報の適用を確認したChromeの検証環境では、一方を失効エラー、もう一方を信頼経路のエラーで拒否しました。このテストでは、接続できたことを安全の証拠にはできません。

Appleは、一部のコマンドラインツールが独自の証明書一覧を参照し、Appleのブロック情報が同じように適用されない場合を説明しています。ブラウザで確認するだけでなく、APIや業務アプリの実際の接続環境でも確認が必要です。Appleの公式説明

自社サイトのSSL証明書を確認する12項目

確認結果は「確認済み・要対応・未確認・対象外」に分け、担当者・期限・根拠を残してください。分からない項目は、保守会社への質問に使えます。

まず自社の構成と対象範囲を調べる

01HTTPSを使う接続先を一覧にする

会社サイト、ECサイト、会員画面、フォーム、管理画面、APIなど、業務で使うホスト名を洗い出します。トップページとは別のサブドメインを使っている機能も含めます。

02証明書の管理者と連絡先を確認する

制作会社、保守会社、レンタルサーバー、クラウドサービスのうち、誰が証明書を管理しているか確認します。SaaSの証明書は、サービス提供元へ対応状況を問い合わせます。

03有効期限・発行元・認証経路を記録する

ブラウザの証明書表示は確認の入口になります。技術担当者には、実際の接続で提示される証明書と、利用するブラウザが構築する中間・ルート認証局までの経路を確認してもらいます。

04問題の中間認証局とG3ルートへの該当を確認する

Google・Appleなどの公表情報と照合します。問題の中間認証局にはAAA Certificate Servicesへつながる経路もあるため、「G3というルート名ではない」という理由だけで対象外と判断しないでください。

対応方針と設定を確認する

05証明書の購入先・提供元へ交換方法を確認する

対象なら、利用するブラウザやアプリで信頼される別系統への再発行・交換を依頼します。同じ認証経路のまま有効期限だけを延ばしても、信頼停止への対応にはなりません。

06作業担当・対応日・利用者への影響を決める

変更するホスト、作業時間、確認担当、停止や接続切断の可能性を整理します。自動更新を利用している場合も、今回の交換を誰が行うか確認してください。

07中間証明書と配信設備まで設定を確認する

サーバー証明書だけでなく、中間証明書の設定も確認します。CDNやロードバランサーなど、利用者のHTTPS接続を受ける設備が別にある場合は、その設備の証明書も対象です。

08API・業務アプリ側の証明書管理を確認する

アプリがOSやブラウザとは別の証明書ストアを使う場合があります。開発・運用担当者に、証明書一覧や関連ソフトの更新、特定の証明書・鍵を固定して検証する設定への影響を確認してもらいます。自社サイトの証明書が対象外でも、外部サービスへ接続するアプリ側の更新状況は別に確認します。

切り替え後に業務が動くことを確かめる

09実際に使うブラウザと端末で確認する

パソコンとスマートフォン、業務で利用する主要ブラウザで、警告なく接続できるか確かめます。ブラウザ・OSの版と確認日時も残します。

10フォーム・ログイン・注文を確認する

トップページの表示だけで終わらせず、入力、送信、完了画面まで確認します。注文・決済はテスト環境や提供元指定の手順を使い、本番で行う場合は発送・課金などの処理を関係者と調整します。

11サーバー間通信と自動処理を確認する

外部API、受注連携、Webhook、定時バッチなどを、実際に稼働する環境で確認します。担当者のパソコンから接続できても、サーバー上の処理が動くとは限りません。

12完了の根拠と次回の管理方法を残す

新しい証明書の認証経路・有効期限、確認した機能、未確認の範囲を記録します。証明書の更新通知に加え、発行元の重要通知を誰が受け取り、誰が対応を判断するか決めておきます。

保守会社への確認には、この文面を使えます

当社サイトのSSL証明書について、eMudhra問題の影響を確認したく、以下を教えてください。

1. 確認したホスト名と、証明書の発行元・中間認証局・ルート認証局。
2. 問題の中間認証局、またはemSign ECC Root CA - G3への依存の有無。クロス署名による別経路も含めた判定根拠。
3. 対応が必要な場合の交換方法、作業担当、対応予定日、費用、利用者への影響。
4. 切り替え後に確認するブラウザ・端末・業務機能と、確認対象に含まれない範囲。

フォーム・会員ログイン・注文・外部API連携など、当社が利用する機能も確認したいと考えています。対象外と判断できた場合も、その根拠をお知らせください。

「期限内です」「自動更新なので大丈夫です」という回答だけでは、今回の確認は完了しません。対象への該当と、その判断に使った認証経路を確認してください。

証明書エラーが出ている場合の対応

すでに警告が出ている場合は、URL、発生日時、端末・ブラウザ、エラー表示を記録し、保守担当へ連絡してください。画面を共有する際は、認証情報や顧客情報が写り込んでいないか確認します。

警告を無視して進むことや、証明書検証を無効にすることを、利用者や担当者に案内しないでください。 接続先が正しい相手かどうかを確認する仕組みが失われます。CERT-Inの推奨対策

証明書エラーには、期限切れ、ホスト名の不一致、中間証明書の不足、端末の時刻など、ほかの原因もあります。eMudhra問題と決めつけず、表示内容と実際の証明書を確認して原因を切り分けます。

不審な改ざんやログインなども見つかった場合は、証明書の修正と並行して、不正アクセス・情報漏えいの初動対応を進めてください。

SSL証明書の確認・切り替えをレイズに相談する

「どの会社が証明書を管理しているか分からない」「保守会社の回答をどう判断すればよいか分からない」という段階からご相談いただけます。

株式会社レイズでは、SSL証明書の発行元・認証経路の調査、必要な証明書の切り替え、切り替え後の接続・業務機能の確認に対応します。対象システムと作業範囲を確認し、調査・改善作業は事前にお見積もりします。

公開Webサイトの基本設定を確認したい方は、無料セキュリティチェックも利用できます。eMudhraの影響対象の判定や、社内アプリ・外部APIを含む確認は、個別にご相談ください。

参考資料と検証の出典

• Google：eMudhra中間認証局への対応とChrome Root Storeの変更
• Apple：問題のあるeMudhra中間認証局とルート証明書への対応
• CERT-In：eMudhra中間認証局の秘密鍵に関する注意喚起
• eMudhra：証明書セキュリティ事案に関する声明
• レイズ代表のnote：SSL証明書は期限内でも使えなくなる？自社サイトとHTTPS実験で検証

検証は2026年10月26日にCodexで操作を自動化し、接続結果とログを記録しました。実測結果はその時点の条件によるものです。Chromeの10月27日の変更は情報確認時点では予定であり、展開状況は上記の公式情報をご確認ください。