会社サイトでSSL警告が出たら、警告を無視してログインや問い合わせを続けず、表示されたURLとエラー内容を確認します。証明書の期限切れだけでなく、名前の不一致や、端末の時刻のずれでも警告は出ます。

社外のスマートフォンでも同じURLで警告が出るなら、サイト側の証明書を優先して調べます。社内の一台だけなら、端末や社内ネットワークの問題も考えられます。原因が分からない段階で証明書を買い直したり、DNSを変更したりする必要はありません。

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

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

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

問い合わせが来ている場合は、技術的な調査の完了を待たずに、入力を止める案内と代替窓口を伝えられます。原因が判明する前に「問題ありません」と案内するのは避けるべきです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

自動更新の失敗が原因なら、更新通知が現在の担当者へ届く設定かも見直します。CDNを使う場合は、元サーバーだけでなく、訪問者が受け取る証明書の監視が再発の早期発見に役立ちます。

なお、アドレス欄にHTTP接続を示す「保護されていない通信」が出る場合と、HTTPS接続時の全画面の証明書警告は別です。前者ならHTTPSで開けるか、後者なら証明書の期限・名前・信頼性を調べます。表示の文言が分かるだけでも、対応する場所を絞れます。