2026.09.08

「この接続ではプライバシーが保護されません」が出たら？原因の切り分けと、顧客影響を最小限に抑える対応手順

執筆者情報

中村圭介

株式会社カジヤ/代表取締役　男性向けファッション通販サイト運営の会社を経験し、現職に至る。デザインや開発から、ECやメディアのコンサルティングまでを一貫して行う。お付き合いのあるお客様の事業を成功に導けるように、再現性のある成長支援ができる会社を目指す。

【AIによる要約】
– 警告の原因は期限切れ・中間証明書の不足・リダイレクトループの3つに絞られ、有効期限を見るだけで原因を切り分けられます。
– まず警告画面で証明書の有効期限とエラー内容を確認します。期限切れならサーバー会社経由で更新、残りはHTTPSリダイレクト設定の見直しです。
– 実務で最多なのはLet’s Encryptの自動更新の失敗です。残日数を月次で監視する体制が再発防止の分かれ目になります。

朝いちばんに届く、あの警告画面

「自社のサイトを開いたら『この接続ではプライバシーが保護されません』という赤い警告が出た」「お客様から『サイトが開かない』と連絡が入った」——Web担当者の方から、このような相談を受けることは珍しくありません。

Chromeでは「この接続ではプライバシーが保護されません」、Safariでは「この接続はプライベートではありません」と表示されるこの警告。実は原因は1つではなく、症状が同じでも対応方法がまったく違うことがあります。誤った対処をすると、証明書を買ってきたのに直らなかったり、顧客影響が長引いたりします。

本記事では、当社がこれまで300社以上の企業サイト・Webシステムの支援で実施してきた切り分け手順を、自社で対応すべき範囲とプロに任せるべき範囲の境界まで含めて整理します。

警告画面と証明書のイメージ

なぜ「放置できない」のか——警告の先で起きること

この警告はブラウザの親切設計ですが、その裏側で起きていることを知っておく必要があります。

訪問者が離れる: セキュリティ警告が表示されたページへのアクセスは、多くの訪問者に敬遠されます。ECサイトなら注文がそのまま止まります
「サイトが壊れている」という印象が拡散する: 警告画面のスクリーンショットが顧客や取引先に送られると、実態以上に深刻な印象を持たれます
証明書期限切れは「管理の停止」のサイン: 証明書の自動更新が止まっているサイトは、OSやCMSのメンテナンスも止まっている可能性が高く、セキュリティ事故の前兆であることが少なくありません

当社は自社でもECサイトやWebサービスを運営しているため、証明書の期限切れ1つで注文と問い合わせが止まる重みを当事者として知っています。だからこそ、この警告は「怖いから消したい」ではなく「1分で切り分けて影響を止める」ための即応手順を持つべきだと考えています。

まず1分で確認する：証明書の有効期限

警告画面（Chromeであれば「詳細設定」→「○○.co.jp にアクセスする（安全ではありません）」の下にある「詳細」）またはサイトの鍵アイコンから、証明書の有効期限を確認してください。ここで原因の大半が判別できます。

切り分けの全体像

有効期限の表示	推定原因	主な対応
過去の日付で切れている	証明書の期限切れ（自動更新の失敗）	サーバー会社経由で更新。Let’s Encryptなら更新処理を再実行
未来の日付で有効なのに警告が出る	中間証明書の不足	サーバー設定の修正（プロの領域）
未来の日付・別のドメインの名前	証明書の取り違え、設定ミス	サーバー設定の修正（プロの領域）
期限・内容が正常なのに出る	リダイレクトループや混在コンテンツ	HTTPSリダイレクト設定の見直し

エラー文のNET::ERR_CERT_DATE_INVALIDなら期限切れ、ERR_CERT_AUTHORITY_INVALIDなら中間証明書や設定の問題、ERR_TOO_MANY_REDIRECTSが一緒に出るならリダイレクトループ、と目安になります。

原因別の対応手順

ケース1：期限切れ（最頻出。Let’s Encryptの自動更新失敗に注意）

実務で最も多いのがこのケースです。しかも注意すべきは、「自動更新されているから大丈夫」という思い込みです。

現在主流のLet’s Encrypt証明書は有効期限が90日と短く、多くのレンタルサーバーでは自動更新の仕組みが動いています。しかし、当社が現場で見てきた限り、実際に期限切れで警告が出たサイトの大半は「自動更新が過去のどこかのタイミングで静かに失敗していた」パターンです。

サーバーの容量不足や一時的なエラーで更新処理が1回失敗したまま通知に気づかない
サーバーの移行やCMSの改修の際に更新処理が壊れたまま運用が続く
更新通知のメールが担当者の個人アドレスに届いていて、担当者が退職した後に読まれなくなる

自社で確認・対応できること:

サーバー会社のコントロールパネルからSSL設定画面を開き、手動更新（再発行）ができるか確認する
手動更新のボタンがない・やり方が分からない場合は、サーバー会社のサポートに「証明書の期限切れ。更新を依頼したい」と1本連絡するだけで解決するケースが多い
更新後に必ず自分の端末（シークレットモード推奨）でサイトを開き、警告が消えたことを確認する

ケース2：中間証明書の不足

証明書は「サーバー証明書」と「中間証明書」がセットで初めて正しく検証されます。中間証明書がサーバーに正しく設定されていないと、証明書そのものは有効なのに警告が出る状態になります。

この場合、担当者には見分ける手段がほぼありません（期限は有効に見えるため）。設定ファイルを触る必要があるため、自社対応の範囲外と判断してください。サーバー会社か保守業者に「中間証明書の設定を確認してほしい」と依頼します。作業自体は短時間で終わることが多いのですが、触る場所を間違えると HTTPS が完全に応答しなくなるため、プロの領域です。

ケース3：リダイレクトループ

「常時SSL化」の設定変更のあとなどに、HTTP→HTTPS→HTTP→…と転送が無限に繰り返され、ブラウザが諦めてエラーを出すパターンです。ERR_TOO_MANY_REDIRECTSが表示されたらこれを疑います。

直近で「常時SSL化」「リダイレクト設定」「CDN導入」の作業をしたかを思い出す
WordPressのアドレス設定（設定→一般のURL）が http と https で混在していないか確認する
レンタルサーバーのコントロールパネルや .htaccess に、重複したリダイレクト設定が書き込まれていないか確認する

心当たりのある設定変更を自分で元に戻せるなら戻して様子を見ます。.htaccessの記述を自分で判断して編集するのは、1文字違えるだけでサイト全体が白紙になる作業なので、これも無理をせずプロへ。

ケース4：期限切れでもないのに「サイトが開かない」

まれに、DNSの名前解決やサーバー自体の障害が原因で、SSLの警告に見えるエラーが出ることがあります。他のサイト（例：Google）が同じ端末で開けるなら端末側の問題ではなくサーバー側の異常です。その場合はサーバー会社の障害情報を確認し、必要ならサーバー会社へ連絡します。

対応中に顧客影響を最小限にする3つの工夫

告知を早く出す: トップページ以外（例：別ドメインのページやSNS）で「証明書更新作業のため一時的に警告が表示されます。現在新しい証明書へ更新中です」と告知するだけで、不安と問い合わせが大幅に減ります
更新作業は影響の少ない時間帯に: 証明書の再発行自体は数分で終わることが多いですが、設定修正を伴う場合はアクセスの少ない早朝や夜間を選びます
確認は複数端末・シークレットモードで: 更新後の確認は、キャッシュの影響を避けるためシークレットモード＋可能ならスマートフォン実機でも行います