会社サイトを開いた顧客から「安全ではないと表示された」と連絡が来たとき、最初に行うのは証明書の再発行ではありません。警告中のページで問い合わせや決済を続けないよう案内します。発生したURL・時刻・利用環境も残します。

SSL警告は証明書の期限切れだけでなく、名前の不一致や認証経路の問題でも起こります。端末時刻や社内ネットワークに原因がある場合もあります。利用者保護から証拠の記録へ進み、その後に影響範囲を確認すると、原因を増やさず復旧できます。

最初の案内は「警告を無視しない」に統一する

全画面の警告が出ている間は、利用者に詳細設定から進むよう案内しません。ログイン情報・問い合わせ内容・カード情報を入力せず、いったんページを閉じてもらいます。Google Chromeの安全性表示に関する案内でも、安全でない、または危険と示されたページへ個人情報を入力しないよう説明されています。

会社側では、問い合わせ窓口・営業・広報・サイト管理者で案内をそろえます。担当者ごとに「こちらでは開けるので問題ない」「警告を無視してよい」と回答すると、利用者へ危険な判断を任せることになります。代替の問い合わせ先が必要なら、警告が出ている同じサイト上ではなく、確認済みの電話番号や別経路を案内します。

障害の責任者は、サイトを直す担当と利用者へ告知する担当を分けておくと動きやすくなります。技術担当が調査中でも、受付担当は入力停止と代替手段を案内できます。ここでの目的は原因を断定することではなく、調査が終わるまで新たな情報入力を発生させないことです。

正確なURLと警告内容を記録する

「トップページで警告が出た」という連絡だけでは、原因を絞れません。アドレス欄のURLは省略せず、wwwの有無とサブドメインまで残します。発生時刻・画面のスクリーンショット・エラーの文言も必要です。リンクをクリックした直後か、別ページへ移動した後かも、問題の接続先を探す手がかりになります。

あわせて端末の種類・ブラウザー・接続した回線を確認します。一人の社用パソコンだけなのか、社外のスマートフォンでも再現するのかで、調査対象は変わります。端末時刻が大きくずれている場合や、社内のプロキシやセキュリティ製品が通信を検査している場合は、公開サイトが正常でも特定環境だけ警告になることがあります。

スクリーンショットへ個人情報や社内情報が写る場合は、共有先を障害対応者へ限定します。記録は単なる報告資料ではありません。修正前にどの証明書が見えていたか、どの経路で再現したかを残すことで、原因とは関係のない設定を次々と変えることを防ぎます。

社外の複数環境で影響範囲を分ける

記録したURLを、社内とは異なる回線と端末から確認します。社外でも同じ警告が出るなら、公開サイト側の問題を優先します。

社内だけなら端末時刻・ソフトウェア更新・社内DNSを調べます。プロキシと通信検査用証明書も候補に残します。一台だけの結果で全利用者へ安全宣言を出さないことが大切です。

公開側を調べるときは、利用者が実際に受け取った証明書を見ます。RFC 5280に基づく検証では有効期間と信頼できる認証局までの経路が確認されます。また、RFC 6125に沿って接続先のホスト名と証明書の名前が照合されます。期限、名前、認証経路のどこが警告に結びついたかを分けます。

CDNやロードバランサーを使っている場合、サーバー管理画面の証明書と公開中の証明書が一致しないことがあります。DNSが古い接続先も返していないか、複数の入口の一部だけ古い証明書を返していないかも確認します。証明書ファイルが更新済みという報告だけでは、利用者側の復旧確認にはなりません。

原因を一つずつ直して公開URLで確かめる

期限切れなら、証明書の更新と各接続先への配備を見直します。名前の不一致なら、実際に使うホスト名を含む証明書と設定が必要です。

認証経路の不足なら中間証明書を含む配備を確認します。端末や社内回線だけの問題なら、公開サイトのDNSや証明書を変更しません。その環境の時刻・信頼設定・プロキシを調べます。

証拠を取る前にDNSと証明書を同時に変更すると、何が原因だったのか分からなくなります。変更は一つずつ行い、時刻・担当者・変更前後の値を記録します。復旧後は問題が出たURLだけでなく、非wwwとwwwも社外回線から確認します。問い合わせフォーム・ログイン画面・公開中のサブドメインも対象です。

ブラウザーの履歴やキャッシュの影響を避けて確認します。公開中の証明書は期限・ホスト名・認証経路を改めて調べます。複数台構成では接続ごとに結果が変わらないかも見ます。警告が一度消えたことより、想定するすべての入口が同じ正常な状態を返していることを復旧条件にします。

復旧案内には確認範囲と時刻を書く

利用者への案内は「SSLを直しました」だけで終わらせません。発生したURL・影響した時間帯・現在確認できている範囲を簡潔に示します。個人情報を入力した可能性がある利用者への対応が必要なら、社内のセキュリティ責任者や法務を含めて判断します。技術担当だけで影響なしと決めつけない方が安全です。

障害記録は、最初の通報から利用者案内までを時系列で残します。警告内容・再現環境・原因・変更内容・復旧確認が途中の経過になります。更新通知が旧担当者へ届いていた、CDNだけ監視対象から外れていたといった管理上の原因も、技術的な修正と分けて記録します。

次回に備えるなら、公開URLから証明書の期限・名前・認証経路を監視します。警告になる前に複数の担当者へ通知します。

警告後の対応手順は、入力停止から証拠採取へ進む形で共有します。その後に社外確認と復旧判定を行う流れです。こうしておくと、担当者の経験に頼らず、利用者の安全を基準に初動をそろえられます。