WordPressサイトへアクセスした際に突然「この接続ではプライバシーが保護されていません」や「NET::ERR_CERT_DATE_INVALID」といった警告画面が表示され、Webサイトの閲覧が完全に遮断されてしまうトラブルが多発しています。
企業のオウンドメディアやコーポレートサイト、ECサイトにおいて、SSL/TLS証明書の有効期限切れや更新エラーが発生すると、訪問者に強い不安を与えるだけでなく、直帰率の急増やコンバージョン機会の損失、検索エンジンの評価下落（SEOへの悪影響）に直結します。
多くのレンタルサーバーでは「Let’s Encrypt」をはじめとする無料独自SSLの自動更新機能が標準提供されていますが、DNS設定の変更、ドメイン移管、.htaccessの記述ミス、WAF（Web Application Firewall）による遮断など、些細な環境変化が原因で自動更新が失敗することがあります。
本記事では、SSL証明書の更新エラーが発生する技術的なメカニズムから、主要レンタルサーバー別の手動再発行手順、更新後に発生しやすいリダイレクトループや混在コンテンツの復旧策まで、企業のWeb担当者が安全かつ最短でサイトを正常化できる具体的な手順をわかりやすく解説します。
「保護されていない通信」ブラウザ警告の原因とSSL証明書期限切れの仕組み
WebブラウザがWebサイトにアクセスする際、安全な通信路が確立されているかを検証するためにSSL/TLS証明書がチェックされます。この検証プロセスで問題が検知されると、ブラウザは訪問者の安全を守るためにページ表示を即座にブロックし、警告画面を出力します。
まずは、画面上に表示されているエラーコードの意味を正しく理解し、問題の本質を切り分けましょう。
代表的な警告表示（NET::ERR_CERT_DATE_INVALID / NET::ERR_CERT_AUTHORITY_INVALID）の意味
ブラウザ（Google ChromeやMicrosoft Edge、Safariなど）に表示されるエラーメッセージには、原因に応じた固有のエラーコードが含まれています。
| エラーコード | 主な発生原因 | 深刻度・影響範囲 |
|---|---|---|
| NET::ERR_CERT_DATE_INVALID | SSL証明書の有効期限が切れている、または有効期間開始前 | 最頻出。サイト訪問者全員のアクセスがブラウザによってブロックされる。 |
| NET::ERR_CERT_AUTHORITY_INVALID | 信頼された認証局（CA）から発行されていない、または中間CA証明書が欠落している | 自己署名証明書（オレオレ証明書）の使用やサーバー側の中間証明書設定不備で発生。 |
| NET::ERR_CERT_COMMON_NAME_INVALID | 証明書に記載されたドメイン名（コモンネーム/SAN）とアクセス先URLが一致していない | 「wwwあり・なし」の不整合やサブドメインの未設定時に発生。 |
| SSL_ERROR_RX_RECORD_TOO_LONG | HTTPSポート（443番）に対してプレーンHTTPで応答が返っている | サーバーの仮想ホスト（VirtualHost）設定ミスやSSL未適用ポートへの接続で発生。 |
実務上で最も遭遇頻度が高いのが「NET::ERR_CERT_DATE_INVALID」です。このエラーは、クライアント端末の日時設定が著しく狂っている特殊なケースを除き、ほぼ100%「WebサーバーにインストールされているSSL証明書の有効期限が切れている」ことを示しています。
訪問者は「危険なサイト」と認識して即座に離脱するため、数時間放置されるだけでもビジネス上の甚大な機会損失を招きます。
無料SSL（Let’s Encrypt等）の自動更新サイクルと失効メカニズム
現在、多くのレンタルサーバーやクラウド環境で利用されている無料独自SSL「Let’s Encrypt」は、証明書の有効期限が90日間と短めに定められています。この短期間設計は、万が一秘密鍵が漏洩した場合の不正利用リスクを最小化するための国際的なセキュリティ標準に基づくものです。
90日ごとの手動更新は現実的ではないため、サーバー側でcronなどの定期実行プロセス（ACMEクライアント）が稼働し、有効期限が切れる約30日前からバックグラウンドで自動更新を試みる設計になっています。
【Let's Encryptの標準的な更新タイムライン】
Day 0 Day 60（残り30日） Day 90
|----------------|-----------------------------------|
[ 証明書有効期間 ] [ 自動更新の定期試行フェーズ（毎日実行） ] [ 期限切れ・警告発生 ]
通常であれば、残り30日の期間中にサーバーが認証局（Let’s Encrypt）と通信して自動的に新しい証明書を取得・適用します。しかし、この更新フェーズでエラーが30日間連続して発生し続けると、担当者が気付かないまま90日目を迎え、ある日突然Webサイトが「保護されていない通信」となって閉鎖状態に陥ってしまうのです。
SSL証明書の自動更新が失敗する主な技術的要因
自動更新はバックグラウンドで人知れず行われるため、エラーが発生してもメール通知を見落としていると事態の発覚が遅れます。自動更新が失敗する背景には、主に以下に挙げる4つの技術的要因が存在します。
DNSレコード・ネームサーバー設定の不整合（ドメイン移管やDNS変更の影響）
Let’s Encryptの自動更新で最も広く用いられている検証方式が「HTTP-01チャレンジ」です。
HTTP-01チャレンジでは、認証局の検証サーバーがドメインのWebサーバーに対して以下のURLへHTTPリクエストを送信し、所定のトークンファイルが存在するかを確認します。
http://example.com/.well-known/acme-challenge/{トークン文字列}
このとき、以下のようなDNS設定の不整合があると検証サーバーが正しいWebサーバーへ到達できず、認証が失敗します。
- ドメイン移管後のネームサーバー切り替え漏れ: ドメインの管理事業者を移管した際、参照先のネームサーバーが旧サーバーのままになっている。
- Aレコード・AAAAレコードのズレ: DNSサーバーでIPv6（AAAAレコード）を設定しているが、Webサーバー側でIPv6の仮想ホストが正しく構成されていない場合、認証局がIPv6を優先してアクセスし通信失敗となる。
- 外部DNS（Cloudflare等）の設定不備: プロキシ（CDN）を経由させている場合、オリジンサーバーへの通信プロトコル設定の食い違いによって認証トークンが返却されない。
.htaccessによる過剰なリダイレクトと認証ファイル（.well-known）へのアクセス遮断
WordPress環境では、常時SSL化やセキュリティ向上のために.htaccessへ様々なリライトルールを記述します。しかし、このリライトルールが認証ディレクトリへのアクセスを遮断してしまう事例が多発しています。
たとえば、すべてのHTTP通信をHTTPSへリダイレクトするルールや、Basic認証、IPアドレス制限が設定されていると、認証局のボットが/.well-known/acme-challenge/内のファイルを読み取れず、403 Forbiddenやリダイレクトエラーとなって更新が弾かれます。
.htaccessによるACMEチャレンジの遮断を防ぐためには、常時SSL化ルールの前に認証ディレクトリを除外する記述を配置することが鉄則です。
# /.well-known/acme-challenge/ へのアクセスをリダイレクトから除外する設定例
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/\.well-known/acme-challenge/ [NC]
RewriteRule ^ - [L]
</IfModule>
WAFやアクセス制限設定による認証局サーバーからの通信ブロック
レンタルサーバーに標準装備されているWAF（SiteGuardやmod_securityなど）や「海外IPアクセス制限」が、Let’s Encryptの検証サーバーを攻撃と誤認して遮断してしまうケースがあります。
Let’s Encryptの検証サーバーは世界中の複数拠点（米国や欧州など）から分散してアクセスを行っており、IPアドレスは固定されていません。そのため、「海外からのPOST/GETリクエストをすべて拒絶する」設定や、セキュリティプラグインのBot遮断機能が有効になっていると、チャレンジファイルの取得に失敗して更新が止まります。
CAAレコードの設定による認証局発行制限
DNSのレコード種別のひとつに「CAA（Certification Authority Authorization）レコード」があります。これは、ドメインの管理者が「どの認証局に証明書の発行を許可するか」を宣言するセキュリティ設定です。
過去に他社の商用SSL（DigiCertやGlobalSignなど）を導入した際にCAAレコードを追加したまま放置していると、Let’s Encryptによる証明書の発行が明示的に拒絶されます。
# Let's Encryptを許可していないCAAレコードの例
example.com. IN CAA 0 issue "comodoca.com"
# Let's Encryptを許可するためのCAAレコード追加例
example.com. IN CAA 0 issue "letsencrypt.org"
自社ドメインのCAAレコードにletsencrypt.orgが含まれているか、DNS設定を再確認する必要があります。
主要レンタルサーバー別：SSL証明書の手動更新・再発行手順
SSL証明書が切れてしまった場合、自動更新プロセスの次回実行を待つ猶予はありません。各レンタルサーバーの管理パネルから手動で証明書を再申請・再発行し、即座にサイトを復旧させる必要があります。
ここでは、国内シェアの高い主要3サーバーにおける具体的な手動再設定手順を解説します。
エックスサーバー：無料独自SSLの再申請手順とエラー解消法
エックスサーバー（Xserver）では、自動更新が失敗すると管理画面にエラー通知が表示されます。手動で再申請を行う手順は以下の通りです。
- サーバーパネルへログインし、「ドメイン」カテゴリにある「SSL設定」をクリックします。
- 対象ドメインの「選択する」をクリックし、現在のSSL証明書一覧を確認します。
- エラーが発生している場合、ステータスに「更新未完了」またはエラー内容が表示されています。「独自SSL追加」タブをクリックします。
- 対象ドメインを選択し、「確認画面へ進む」＞「追加する」を実行します。
もし「DNS参照先が当サーバーではありません」「認証ファイルが確認できません」といったエラー画面が表示された場合は、以下の項目を一時的に確認・対処してください。
- サーバーパネルの「セキュリティ設定」＞「WAF設定」を一時的にすべてOFFにする。
.htaccessファイルの先頭に記述されている独自のリダイレクトやBasic認証をコメントアウト（#を付与）する。- 再申請が成功して「反映待ち」になったら、約15分〜1時間程度で証明書が適用されます。適用確認後、WAFやセキュリティ設定を元に戻します。
ConoHa WING：独自SSLのON/OFF切り替えとDNS浸透待ちへの対処
ConoHa WINGでは、無料独自SSLの再発行機能が「利用設定のトグルスイッチ」に統合されています。
- ConoHa WINGコントロールパネルへログインします。
- 左メニューの「サイト管理」＞「サイトセキュリティ」を開き、上部タブの「独自SSL」を選択します。
- 「無料独自SSL」アコーディオンを開き、対象ドメインの「利用設定」を確認します。
- 利用設定が「ON」のままエラーになっている場合は、一度「OFF」に切り替えて設定を保存し、数分待ってから再度「ON」に変更します。この操作によって再申請プロセスが強制的にトリガーされます。
再設定時に「DNS設定が正しく行われていません」と表示される場合は、ドメインのネームサーバーがConoHa WING（ns-a1.conoha.io / ns-a2.conoha.io 等）を正しく向いているか、あるいはAレコードがサーバーのIPアドレスと一致しているかを確認してください。DNSの変更直後である場合、キャッシュが浸透するまで数時間から最大24時間程度要することがあります。
さくらのレンタルサーバ：Let’s Encryptの手動再設定と確認項目
さくらのレンタルサーバ（新コントロールパネル）での手動再設定手順は以下の流れです。
- コントロールパネルへログインし、左メニューの「ドメイン/SSL」をクリックします。
- 対象ドメインの右側にある「設定」ボタン（歯車アイコン）をクリックし、「SSL証明書」を選択します。
- 現在の証明書情報画面が表示されたら、「無料SSL設定（Let’s Encrypt）」ボタンをクリックします。
- 「Let’s Encrypt（無料SSL）の利用」画面で利用規約に同意し、「無料SSLを設定する」を実行します。
さくらのレンタルサーバで申請エラーになる場合、以下の点を確認してください。
- 「SNI（Server Name Indication）」の拡張機能に対応していない極めて古いプランや個別設定が存在しないか。
- コントロールパネルの「セキュリティ」＞「国外IPアドレスフィルタ」が有効になっている場合、一時的に「無効」に設定して再申請を試行する。
- 申請から発行完了までは通常数十分程度かかります。発行完了の通知メールを受信したら、ブラウザからHTTPSでアクセスできるか確認します。
【Webサーバー側のプロセス反映遅延とキャッシュクリア】
コントロールパネル上で「SSL設定完了」と表示されても、Webサーバー（ApacheやNginx）のプロセス再読み込み（リロード）に数分から15分程度のタイムラグが発生することがあります。また、訪問者のブラウザや社内プロキシサーバーに「古い証明書情報（期限切れ状態）」がキャッシュされているケースも少なくありません。復旧確認を行う際は、ブラウザのシークレットウィンドウ（プライベートブラウズモード）を利用するか、Ctrl+F5（MacはCmd+Shift+R）で強力なスーパーリロードを実行して確認しましょう。
【緊急時の技術サポートについて】
DNS設定の不整合やサーバー設定の重複によりSSLの再発行が通らず、サイトが表示されない時間が長引くとSEOや事業に深刻な損失が生じます。自社での切り分けや管理画面の操作に不安がある場合や、早急な復旧が求められるビジネスサイトの場合は、専門エンジニアが直接調査・対応するMozCheck WordPress技術トラブル緊急復旧サポートへご相談ください。
SSL更新後に発生しやすいWordPressトラブルと解決手順
SSL証明書の再発行が完了してサーバー側の暗号化通信が復旧しても、WordPress特有の設定のズレによって二次障害が発生することがあります。ここでは更新前後に併発しやすい代表的な3大トラブルの対処法を解説します。
管理画面（一般設定）のWordPressアドレス・サイトアドレスのhttps統一
サーバーでSSL証明書が有効化されていても、WordPress側の内部設定がhttp://のまま放置されていると、内部リンクの不整合やログイン画面からの意図せぬリダイレクトが発生します。
- WordPress管理画面にログインし、左メニューの「設定」＞「一般」を開きます。
- 以下の2つの項目が両方とも「https://」で始まっているか確認します。
- WordPress アドレス (URL)
- サイトアドレス (URL)
http://になっている場合はhttps://に書き換えて「変更を保存」をクリックします。
もし管理画面自体にアクセスできず設定変更が不可能な場合は、FTPやサーバーのファイルマネージャーからWordPressのルートディレクトリにあるwp-config.phpを編集し、以下の定数を直接定義してURLを強制的に上書きします。
// wp-config.php の編集（/* That's all, stop editing! Happy publishing. */ より上に記述）
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');
混在コンテンツ（Mixed Content）の検出と画像URL一括置換手順
SSL証明書を更新したにもかかわらず、ブラウザのアドレスバーに「完全な鍵マーク」が表示されず、「！」マークや「このサイトへの接続は完全には保護されていません」と表示される現象を混在コンテンツ（Mixed Content）と呼びます。
これは、HTTPSで配信されているWebページの中に、http://で始まる画像、CSS、JavaScript、外部フォントなどのリソースが混在しているために発生します。
【混在コンテンツの特定手順】
Google Chromeで該当ページを開き、キーボードのF12キーを押して「デベロッパーツール（DevTools）」を起動します。「Console」タブを選択すると、以下のような赤字または黄色の警告が出力され、混在しているリソースのURLが特定できます。
Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, but requested an insecure element 'http://example.com/wp-content/uploads/banner.jpg'. This request was automatically upgraded to HTTPS, or this resource should be served over HTTPS.
【Better Search Replaceプラグインによる一括置換手順】
記事本文やウィジェット内にハードコードされたhttp://の画像URLは、データベース内の文字列を一括置換することで迅速に修正できます。
- 管理画面の「プラグイン」＞「新規追加」から「Better Search Replace」をインストールして有効化します。
- 左メニューの「ツール」＞「Better Search Replace」を開きます。
- Search forに「
http://example.com」、Replace withに「https://example.com」を入力します（自社ドメインに置き換えてください）。 - Select tablesで
wp_postsやwp_postmetaなど全テーブルを選択します。 - 「Run as dry run?（テスト実行）」にチェックを入れて実行し、置換対象の件数を確認します。
- 問題がなければ「Run as dry run?」のチェックを外し、本番置換を実行します。
リダイレクトループ（ERR_TOO_MANY_REDIRECTS）が発生した場合の.htaccess修正
SSL証明書の適用後、ブラウザに「このページは正しくリダイレクトされませんでした」や「ERR_TOO_MANY_REDIRECTS」が表示されてサイトが閲覧不能になるケースがあります。
この現象は、リバースプロキシ環境（ConoHa WING、Kinsta、Cloudflare、AWS CloudFrontなど）において、SSLアクセラレータとWebサーバー間の通信が内部的にHTTPで行われている際に発生します。WordPress側が「現在はHTTPでアクセスされている」と誤認し、HTTPSへ強制転送しようとする処理が無限ループに陥ることが原因です。
このリダイレクトループを解消するには、wp-config.phpの先頭（<?phpの直後）に以下のリバースプロキシ認識コードを追記します。
// wp-config.php の最上部に追記
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
この記述を追加することで、プロキシ経由のHTTPS通信をWordPressが正しく検知できるようになり、無限転送が即座に停止します。
なお、.htaccessの記述ミスや設定の衝突によってWebサーバー全体がクラッシュし、ブラウザに真っ白な画面やHTTP 500エラーが返される場合があります。設定ファイルの修正時にシステムエラーが発生した場合は、500 Internal Server Errorの完全ガイドを参考にして原因の切り分けと復元を行ってください。
また、SSL設定の変更と同時にサーバーのPHPバージョンを変更したことでプラグインの非互換エラーが併発しているケースも見受けられます。PHP関連の不具合が疑われる場合は、WordPressのPHPバージョンアップエラー解消完全ガイドの手順に沿って安全に環境を復旧させてください。
SSL更新エラーを未然に防ぐ運用監視体制
SSL証明書の更新エラーは、失効してサイトが停止するまで表面化しにくいという厄介な性質を持っています。トラブルを未然に防ぐためには、「期限切れの前に異常を検知できる仕組み」を運用体制に組み込んでおくことが欠かせません。
証明書有効期限の外部監視ツールの活用
レンタルサーバーの自動更新メールだけに依存していると、担当者の異動やメールアドレスの変更、迷惑メールフォルダへの誤振り分けによって更新失敗のアラートを見落とす危険性があります。
自社サイトの信頼性を維持するためには、外部の死活監視サービスを活用してSSL証明書の残存日数を常時モニタリングすることを推奨します。
- UptimeRobot / MozCheck等の死活監視サービス: Webサイトの死活監視と同時にSSL証明書の有効期限を自動監視し、「有効期限残り30日前」および「残り14日前」のタイミングでSlackやメールに警告通知を送信するよう設定します。
- 定期的なDNS点検のルーティン化: 社内でドメイン管理会社やDNSレコードの変更、CDNの追加設定を行った際には、必ず「SSL自動更新（HTTP-01チャレンジ）の疎通に影響を与えていないか」を確認項目としてチェックリスト化します。
- 証明書有効期間の短縮トレンドへの備え: Web標準化団体や主要ブラウザベンダーでは、セキュリティ強度向上のためにSSL証明書の最大有効期間を現在の90日間からさらに短縮（45日〜30日程度）する議論が進められています。有効期間が短くなれば手動での対応は完全に不可能となるため、強固で途切れない完全自動更新パイプラインの構築がWebサイト運営の標準要件となります。
まとめ：SSL証明書エラーの迅速な復旧と再発防止チェックリスト
WordPressにおけるSSL証明書のエラーは、ドメインやWebサーバー、DNS、WordPress本体の設定が複雑に絡み合って発生します。突発的な障害に見舞われた際は、パニックにならず以下の手順に沿って冷静に対処しましょう。
【SSL復旧・再発防止チェックリスト】
| フェーズ | チェック項目 | 確認内容 |
|---|---|---|
| 1. 現状把握 | エラーコードの確認 | NET::ERR_CERT_DATE_INVALID（期限切れ）か、中間証明書エラーかを確認する |
| 2. 原因特定 | DNS・ネームサーバー | Aレコードやネームサーバーが正しく契約サーバーを向いているか |
| 2. 原因特定 | アクセス制限の確認 | .htaccessやWAF、Basic認証が/.well-known/を遮断していないか |
| 3. 手動復旧 | サーバー管理画面 | レンタルサーバーの管理画面から独自SSLの手動再申請・再発行を実行する |
| 4. 二次障害対策 | WordPressアドレス | 管理画面のURLがhttps://に統一されているか確認する |
| 4. 二次障害対策 | 混在コンテンツ解消 | http://のリソース読み込みを検知し一括置換する |
| 4. 二次障害対策 | リダイレクトループ解消 | プロキシ環境のwp-config.phpにHTTP_X_FORWARDED_PROTOを追記する |
| 5. 再発防止 | 外部監視の導入 | 外部監視ツールを設定し、有効期限切れの兆候を早期検知できる体制を整える |
DNS設定の不整合やサーバー設定の重複によりSSLの再発行が通らず、サイトが表示されない時間が長引くとSEOや事業に深刻な損失が生じます。自力解決が難しい場合や、社内に専門のサーバー管理者がおらず最短でサイトを復旧させたい場合は、MozCheck WordPress技術トラブル緊急復旧サポートへご相談ください。専門のエンジニアが原因の究明からサーバー設定・SSL証明書の正常化まで迅速に代行支援いたします。
コメントを残す