WordPressサイトでアクセス時に「プライバシーの保護に問題がある」といった警告が出ると不安になりますよね。
原因はブラウザ設定やSSL証明書、混在コンテンツ、リダイレクトやプラグインなど多岐にわたり、そのまま放置すると訪問者の信頼低下やSEO悪化につながります。
本記事では原因の見分け方からサーバー側・WordPress側での具体的な修正手順まで、実践的に分かりやすく解説します。
証明書の再発行、中間証明書の確認、常時SSL化やCDN設定のチェックリストを順に紹介するので、段階を追って対応できます。
まずはブラウザ側の簡単な確認から始め、本編で一つずつ問題を潰していきましょう。
WordPressでこの接続ではプライバシーが保護されませんと表示された時の対処
WordPressサイトで「この接続ではプライバシーが保護されません」と表示された場合、原因は複数あり得ます。
ここではまず考えられる主な原因を整理し、ブラウザ側とサーバー側で確認すべき項目をわかりやすく解説します。
主な原因
最も多い原因はSSL証明書に関連する設定不備や期限切れです。
混在コンテンツが原因でブラウザがページを安全でないと判定しているケースも頻繁に発生します。
リダイレクト設定のミスや、不適切なプロキシやCDN設定が影響することもあります。
また、プラグインやテーマの外部リソース読み込みが問題を引き起こす場合もあります。
ブラウザ側の確認項目
まずはブラウザで表示されるエラー詳細を確認してください。
エラーページ上に表示される証明書の発行元や有効期限などは重要な手がかりになります。
- 証明書の発行元と有効期限の確認
- キャッシュとクッキーのクリア
- シークレットモードでの表示確認
- 他のブラウザでの動作確認
- ネットワークやプロキシの使用確認
これらを順に試すことで、ブラウザ固有の問題かサイト側の問題かを切り分けられます。
サーバー側の確認項目
サーバー側ではまず証明書が正しくインストールされているかを確認してください。
中間証明書のチェーン切れや、サーバーでTLS設定が古いプロトコルを使用していないかもチェックします。
ウェブサーバーの設定でHTTPS用のポートが正しく開放されているかどうかも重要です。
さらに、CDNやロードバランサーを利用している場合は、その経路で証明書が適切に扱われているかを確認します。
SSL証明書の期限と種類
証明書の種類や有効期間を把握しておくとトラブル対応が速くなります。
| 証明書タイプ | 発行例 | 有効期間 |
|---|---|---|
| ドメイン検証 DV | LetsEncrypt | 90日 |
| 組織検証 OV | 商用CA | 1年 |
| 拡張検証 EV | 商用CA EV | 1年 |
無料の証明書は短期間で自動更新が必要な点と、企業情報の表示がされない点に注意が必要です。
混在コンテンツ
ページ内にHTTPで読み込まれる画像やスクリプトがあると、ブラウザは警告を出します。
まずはデベロッパーツールでコンソールエラーを確認し、HTTPリクエストを洗い出してください。
外部サービスや広告、フォントなどが原因になることが多いので、読み込み元をHTTPSに変更するか代替を用意します。
リダイレクト設定
HTTPからHTTPSへのリダイレクトが正しく設定されていないと、ユーザーが古いURLに誘導される場合があります。
複数のリダイレクトチェーンはブラウザに悪影響を与えることがあるため、最短ルートでHTTPSへリダイレクトする設定を推奨します。
サーバーの.htaccessやnginxの設定、あるいはWordPressのプラグイン設定を確認してください。
プラグインの影響
SSL関連のプラグインが競合して誤動作を起こすケースがあります。
問題発生時は一度プラグインを無効化して、挙動が変わるかを確認してください。
また、キャッシュ系プラグインやリライトルールを持つプラグインも影響することがあるため注意が必要です。
ローカル開発環境の注意点
ローカルの自己署名証明書はブラウザで信頼されないため、警告が表示されます。
開発環境で検証する場合は正しいホスト名での証明書や、ブラウザに証明書をインポートする手順を整えておくと安全です。
また、環境差により本番では問題ない設定がローカルで再現しないことがあるため、本番環境でも検証することを忘れないでください。
サーバーで行う具体的な修正手順
ここではサーバー側で実際に行うべき具体的な手順をわかりやすく解説します。
証明書の再発行からインストール確認、チェーンの検証、ポートとプロトコルの設定まで順番に確認してください。
証明書の再発行
証明書が期限切れや誤発行の疑いがある場合は、まず再発行を検討してください。
- 新規CSRの作成
- 認証局での再発行申請
- ドメイン検証の実施
- 新しい証明書のダウンロード
- 秘密鍵の安全な保管
特にLet’s Encryptを利用している場合は、自動更新の設定に問題がないかも合わせて確認してください。
ワイルドカードやSANを使用している構成では、対象ドメインが正しく含まれているか注意が必要です。
証明書のインストール確認
再発行した証明書をサーバーに正しく配置することが重要です。
ファイルのパスや所有権、読み込み設定を間違えるとブラウザでエラーが表示されますので丁寧に確認しましょう。
| チェック項目 | 期待される状態 |
|---|---|
| 証明書ファイルのパス | 正しいファイルが存在 |
| 秘密鍵の一致 | 秘密鍵に対応 |
| サーバー設定の読み込み | 設定ファイルで参照 |
| ファイルのパーミッション | 適切な権限設定 |
テスト方法としてはサーバー上で証明書を確認するコマンドを実行し、表示される内容と期待値を突き合わせてください。
ウェブサーバーを再起動して設定が反映されるか確認することも忘れないでください。
中間証明書（チェーン）の確認
ブラウザはサーバーから送られてくる証明書チェーンを検証しますので、中間証明書が欠けていると信頼エラーになります。
認証局から提供される中間証明書をまとめてインストールし、正しい順序で送信するように設定してください。
チェーンの問題はオンラインの検査ツールやopensslコマンドで簡単に見つけられますので、確認後に必要があればCAバンドルを差し替えてください。
ポートとプロトコルの設定確認
TLSは通常ポート443で動作しますので、サーバー側のリッスン設定とファイアウォールの開放状態を確認してください。
古いTLSバージョンや脆弱な暗号スイートを無効化し、TLS1.2以上を優先する設定にすると安全性が向上します。
ロードバランサーやリバースプロキシを利用している場合は、そこで終端されている証明書とバックエンドの設定が一致しているかも確認が必要です。
また、ポート80から443へのリダイレクト設定が正しく働いているかをチェックし、無限ループや誤ったプロトコル切替が発生していないか注意してください。
WordPress側での設定チェックリスト
ここではWordPress側で確認すべき主要な設定項目を分かりやすく整理します。
サーバー側でSSLが有効でも、WordPressの設定が不整合だと警告が出ることが多いため、順番にチェックしてください。
サイトURL設定（HTTP/HTTPS）
まず管理画面の設定＞一般を開き、WordPressアドレスとサイトアドレスがhttpsで始まるかを確認してください。
もしhttpのままになっている場合はここをhttpsに変更し、保存後に表示を確認してください。
大量にURLを書き換える必要があるときは、wp-config.phpでの固定やデータベースの置換を検討できます。
ただしシリアライズされたデータを壊さないよう、Search Replace DBなどのツールを使うと安全です。
常時SSL化の強制設定
訪問者が常にHTTPSで接続できるように、サーバー側またはWordPress側でリダイレクトを設定してください。
Apacheなら.htaccessへの301リダイレクト、nginxならserverブロック内でのリダイレクトが一般的です。
WordPress側ではwp-config.phpにFORCE_SSL_ADMINを追加することで管理画面を保護できます。
またHSTSを導入する場合は慎重になってください、誤設定するとブラウザに長期間キャッシュされるリスクがあります。
SSL関連プラグインの設定
プラグインを使うと混在コンテンツの自動修正や強制リダイレクトが簡単になりますが、設定ミスでループが発生することがあります。
導入前にバックアップを取り、無効化してもサイトが表示されるか確認してください。
使用中の主な機能や優先度を整理しておくと、トラブル対応が早くなります。
- 全ページリダイレクト
- 混在コンテンツ置換
- HSTSヘッダー設定
- 管理画面の保護
プラグインは便利ですが、同じ機能を複数プラグインで重複させないように注意してください。
テーマや外部スクリプトの確認
テーマ内のハードコードされたhttpリンクや、外部スクリプトの読み込み先が問題で警告が出ることがあります。
まずはブラウザの開発者ツールで混在コンテンツを特定し、該当箇所を修正してください。
外部リソースをどう扱うかルールを決めておくと、運用時の迷いが減ります。
| 確認項目 | 対応例 |
|---|---|
| テーマファイル | httpsに書き換え |
| 外部CDN | HTTPS対応のURLへ変更 |
| プラグイン読み込み | 最新化または差し替え |
| インラインスクリプト | 外部化またはプロトコル相対化 |
修正後はキャッシュやオプティマイザ系プラグインのキャッシュをクリアして、実際の表示を必ず確認してください。
ブラウザと端末で試す簡単な対処
「この接続ではプライバシーが保護されません」と表示されたときは、まずサーバーや証明書を触る前に、ブラウザと端末側で手早く確認できる項目がいくつかあります。
ここで紹介する手順は素早く試せて、原因切り分けにも役立ちます。
キャッシュとクッキーの削除
ブラウザのキャッシュやクッキーが古い情報を保持していると、証明書の更新が反映されずエラーが残ることがあります。
サイト単体のキャッシュクリアが可能な場合は、対象ドメインだけを削除してから再読み込みしてください。
ブラウザの全体キャッシュを削除する際は、保存しておきたいログイン情報が消えないよう注意してください。
削除後にページを再読み込みして、エラーが消えるかどうかを確認します。
シークレットモードでの確認
シークレットモードやプライベートウィンドウでは、拡張機能や保存データの影響を受けにくくなります。
そこで一度シークレットウィンドウで該当ページを開き、問題の有無を確認してください。
- URLを直接入力する
- ブックマークを使わない
- 拡張機能を無効化する
- ページをリロードする
シークレットで問題が出ない場合は、通常モードの拡張機能やキャッシュが原因の可能性が高いです。
ブラウザ更新と互換性確認
古いブラウザは新しい暗号化方式や証明書に対応していないことがありますので、まずはブラウザを最新版に更新してください。
別のブラウザで同じページを開いて、エラー状況が変わるかどうかも確認します。
| ブラウザ | 推奨バージョン |
|---|---|
| Chrome | 最新版 |
| Firefox | 最新版 |
| Safari | 最新版 |
| Edge | 最新版 |
ブラウザのセキュリティ設定でTLSや暗号スイートが制限されている場合は、設定を見直してください。
別端末・別ネットワークでの検証
スマートフォンや他のPCから同じURLにアクセスして、現象が再現するかを確認してください。
自宅のWi‑Fiや会社のネットワーク、モバイル回線など別のネットワークを使うことで、ISPやルーター由来の問題を切り分けられます。
また、社内ネットワークやプロキシ環境下では中間で証明書が置き換えられている場合があるため、可能ならVPNを切って検証してください。
これらの手順でブラウザ側の問題か、サーバー側の問題かを素早く判断できます。
CDN・DNS・外部サービスの調整
CDNやDNS、ロードバランサーといった外部サービスは、WordPressサイトのSSL状態に大きく影響します。
サーバー側で証明書を正しく設定していても、これらの中間レイヤーで設定がずれていると「この接続ではプライバシーが保護されません」と表示されることが多いです。
CloudflareやCDNのSSL設定
まずCloudflareや任意のCDNを利用している場合は、SSL/TLSモードの設定を確認してください。
CloudflareではOff、Flexible、Full、Full(strict)のモードがあり、推奨はFull(strict)です。
このモードを選ぶには、オリジンサーバーにも有効な証明書が必要です。
エッジ証明書が有効化されているか、そして自動更新が機能しているかも確認しましょう。
CDN側で「Always Use HTTPS」や「Automatic HTTPS Rewrites」を有効にすると、混在コンテンツの多くを解消できます。
- SSL/TLSモード
- Edge Certificateの有効化
- Always Use HTTPS
- Automatic HTTPS Rewrites
- オリジン証明書の利用
Cloudflareのプロキシ（オレンジクラウド）を使っている場合は、ブラウザとCloudflare間、Cloudflareとオリジン間の両方で証明書が必要になります。
変更の後はCDNキャッシュをパージして、ブラウザで再確認してください。
DNSのCNAME/Aレコード確認
DNSレコードが正しく設定されているかをまずチェックしてください。
Aレコードが正しいIPを指しているか、CNAMEが期待するホスト名を指しているかを確認することが重要です。
Cloudflareを使っている場合は、該当レコードがプロキシ有効（オレンジ）かDNSのみ（グレー）かによって挙動が変わります。
プロキシを有効にしていると、直接オリジンのIPが見えなくなるため、オリジン側の証明書設定が見落とされがちです。
| レコード | 主な用途 |
|---|---|
| A CNAME TXT |
IP割当て ホスト名参照 ドメイン認証 |
| MX AAAA CAA |
メール配送先 IPv6対応 証明書発行制限 |
DNS変更後はプロパゲーションを待つ必要があるため、TTLを短くしてから変更すると切り替えがスムーズになります。
digやnslookupでレコードを確認し、想定外のCNAMEループや誤ったAレコードがないかをチェックしてください。
ロードバランサーの証明書設定
ロードバランサー（LB）を挟んでいる構成では、LBがクライアントに提示する証明書が最も重要です。
LBに証明書が正しくインストールされているか、かつ中間証明書も含めたチェーンが完結しているかを必ず確認してください。
SNIを使う環境では、複数ドメインを扱う場合に証明書の紐づけが正しいかどうかをチェックする必要があります。
バックエンドサーバーとLB間の通信をHTTPSにする場合は、オリジン側にも証明書を設定し、ヘルスチェックがHTTPSで通るか確認してください。
複数のLBノードがある場合は、各ノードでの証明書更新を自動化し、同期漏れが起きないようにしてください。
最後に、openssl s_clientやブラウザで実際に接続して、提示される証明書やチェーンの内容を検証しておくと安心です。
運用開始後に継続して確認すべき項目
運用開始後もSSLや接続に関する項目は定期的に確認する必要があります。
ここでは優先度の高いチェックポイントを分かりやすくまとめますので、運用フローに組み込んでください。
- SSL証明書の有効期限と自動更新設定
- 中間証明書の有無とチェーンの正しさ
- サイト内の混在コンテンツ
- 301リダイレクトとHSTS設定の適用
- プラグインとテーマの更新と互換性
- CDNやCloudflareのSSLモード
- DNSレコードの整合性とTTL
- アクセスログとブラウザエラーの監視
チェックリスト化して定期点検を実施し、問題発生時の対応手順をあらかじめ用意しておくことをおすすめします。