「この接続ではプライバシーが保護されません」原因と対処法
「この接続ではプライバシーが保護されません」は、Chromeがサイトの証明書(SSL/TLS証明書)を信頼できないと判断したときに出る警告です。原因は、サイト側の証明書の問題、通信経路(ネットワーク)の問題、閲覧している端末の問題のいずれかで、Chromeの公式ヘルプもこの3つのどれかに問題があると説明しています。
この記事は、あなたが閲覧者なのかサイト運営者なのかで、やることがまったく違う点を踏まえ、(A)閲覧者側で確認すること、(B)運営者側の原因と対処を明確に分けて説明します。エラーコード(NET::ERR_CERT_DATE_INVALID など)を見れば、どちら側の問題かの見当がつきます。
先に大事な点をひとつ。画面の「詳細設定」から安易に「続行」しないでください。特に、ログインや決済などの個人情報を入力するページでは、通信を第三者に盗み見られたり、改ざんされたりする恐れがあります。内容はChrome・Let's Encryptの公式ドキュメントで2026年10月6日に確認しました。
この接続ではプライバシーが保護されませんと表示される理由
HTTPS通信では、サイトが「自分は本物のこのドメインです」と証明するためにサーバー証明書を提示します。ブラウザーは、その証明書が次の条件を満たすかを確認します。
- 有効期限内であること(端末の日時と比較します)
- アクセスしているドメイン名が、証明書に記載された名前(CN・SAN)に含まれること
- 信頼できる認証局(CA)から発行され、そこまでの証明書の鎖(チェーン)がつながっていること
- 失効していないこと
どれか1つでも満たせなければ、Chromeは通信先を信用できないとして、ページ全体にこの警告を出します。Chromeのヘルプは、このエラーについて「サイト、ネットワーク、デバイスのいずれかに問題があります」と説明しています。
エラーコードで切り分ける
警告画面には「NET::ERR_...」で始まるコードが表示されます。「詳細設定」を開くと確認できます。代表的なものは次のとおりです。
| エラーコード | 意味 | 主な原因の側 |
|---|---|---|
| NET::ERR_CERT_DATE_INVALID | 証明書の有効期限が切れている/まだ有効でない | サイトの期限切れ、または端末の日時のずれ |
| NET::ERR_CERT_COMMON_NAME_INVALID | 証明書の名前とアクセスしたドメインが一致しない | サイト側の設定(ドメイン不一致、www有無) |
| NET::ERR_CERT_AUTHORITY_INVALID | 発行元が信頼できない(自己署名、中間証明書不足など) | サイト側の設定。ネットワークやセキュリティソフトの場合も |
| NET::ERR_CERT_REVOKED | 証明書が失効している | サイト側(再発行が必要) |
同じコードでも、原因が閲覧者側にある場合と運営者側にある場合があります。次の章から、それぞれの確認手順を説明します。
【閲覧者向け】まず確認すること(A)
あなたがサイトを見る側なら、次の順で確認してください。複数のサイトで同じ警告が出るなら、端末またはネットワークが原因の可能性が高く、特定の1サイトだけなら、そのサイト側の問題の可能性が高い、という切り分けが出発点になります。
1. パソコン・スマートフォンの日時を確認する
証明書の有効期限は端末の日時と比べて判定されるため、日付や時刻が大きくずれていると、有効な証明書でも NET::ERR_CERT_DATE_INVALID になります。Windowsなら「設定」→「時刻と言語」→「日付と時刻」で、「時刻を自動的に設定する」と「タイム ゾーンを自動的に設定する」をオンにし、「今すぐ同期」を押します。スマートフォンも、設定で日時の自動設定をオンにしてください。
2. 別のネットワークで試す(公共Wi-Fiに注意)
ホテル、カフェ、駅などの公共Wi-Fiでは、接続前の認証画面(キャプティブポータル)が通信に介入して証明書エラーになることがあります。また、悪意あるアクセスポイントが通信に割り込んでいる可能性もゼロではありません。スマートフォンのモバイル回線など、別の回線で同じサイトを開いてみてください。別の回線で正常に開けるなら、元のネットワークに原因があります。公共Wi-Fiでは、エラーを無視して先に進むことは避けてください。
3. セキュリティソフトの設定を確認する
一部のウイルス対策ソフトは、安全確認のためHTTPS通信を一度中継して検査します(SSLスキャン、HTTPSスキャン)。この仕組みが原因で証明書エラーが出ることがあります。Chromeのヘルプも、ファイアウォールやウイルス対策ソフトが接続をブロックしていないかの確認を案内しています。ソフトの更新や、該当機能の設定を見直してください。
4. Chromeの状態を整える
Chromeを最新版に更新し、いったん閉じて開き直します。シークレットモードで開く、拡張機能を無効にする、閲覧データを削除する、といったChrome公式ヘルプの手順も有効です。
5. それでも出るなら「続行」しない
上記を行っても、特定のサイトだけで警告が出るなら、サイト側の問題です。ログイン、会員情報、クレジットカードの入力が必要なサイトでは、運営者が直すまで利用を控え、サイトの問い合わせ窓口や公式SNSで連絡するのが安全です。急ぎの場合は、公式アプリや、ブックマークではなく公式の案内に載っているURLを使い直してください。「詳細設定」から「(サイト名)にアクセスする(安全ではありません)」を選ぶと、通信内容が第三者に見られたり書き換えられたりする恐れがあります。なお、HSTSという仕組みを使っているサイトでは、続行用のリンク自体が表示されないことがあります。
【運営者向け】SSL証明書エラーの原因と対処(B)
あなたがサイトを運営する側で、閲覧者から「警告が出る」と言われたなら、次の原因を順に疑ってください。まず、第三者の目線で確認できるよう、後述のコマンドで証明書の状態を見ます。
原因1:SSL証明書の期限切れ(ERR_CERT_DATE_INVALID)
最も多い原因です。証明書には有効期限があり、切れると全訪問者に警告が出ます。Let's Encryptの証明書は既定で90日間有効で、公式FAQは「90日の証明書は60日ごとに更新することを推奨」としています。自動更新の設定が壊れている、更新後にWebサーバーを再読み込みしていない、という理由で期限切れになるケースが目立ちます。対処は、証明書を更新して、Webサーバーに反映することです。具体的な手順は後述のcertbotの章を参照してください。
なお、Let's Encryptは2025年6月4日に有効期限が近づいたときの通知メールの送信を終了しました。メールが来ないことを前提に、自動更新と監視を自分で用意する必要があります。
原因2:中間証明書の不足(ERR_CERT_AUTHORITY_INVALID)
サーバー証明書は、中間CA証明書を経由してルートCAにつながります。サーバーが自分の証明書(リーフ証明書)だけを送り、中間証明書を送っていないと、ブラウザーはチェーンを組み立てられません。PCのブラウザーでは補完できても、スマートフォンや一部のアプリで警告が出る、という「環境によって出る」症状が典型です。
対処は、サーバーに設定する証明書ファイルを、中間証明書込みのものにすることです。Let's Encryptなら cert.pem ではなく fullchain.pem を指定します。
# nginx の例
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# Apache の例
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pemLet's Encryptの公式ガイドは、中間証明書は変わり得るため、設定に固定で埋め込まず、ACMEクライアントが取得するものを使うよう案内しています。
原因3:ドメイン名の不一致、wwwの有無(ERR_CERT_COMMON_NAME_INVALID)
証明書に書かれたドメイン名(SAN)と、実際にアクセスされたドメインが違うと発生します。例えば、証明書が example.com だけで取得されていて、www.example.com でアクセスすると警告になります。逆も同様です。対処は次のとおりです。
- 証明書を取得するときに、
example.comとwww.example.comの両方を指定する。 - サブドメインが多いなら、ワイルドカード証明書(
*.example.com)を検討する。Let's Encryptでワイルドカードを取得するにはDNS-01方式の認証が必要です。ただし、*.example.comはexample.com自体を含まないため、両方を指定します。 - 共有サーバーや複数サイトを同居させている場合は、サイトごとに正しい証明書が割り当てられているか(バーチャルホストの設定)を確認する。
原因4:自己署名証明書、その他
開発用の自己署名証明書を本番に使っている、発行元が信頼されていない、といった場合も AUTHORITY_INVALID になります。公開サイトには、公的な認証局が発行した証明書を使ってください。そのほか、証明書が失効している場合(ERR_CERT_REVOKED)は、再発行が必要です。
無料でできるSSL証明書の確認手順(openssl・curl)
ブラウザーに頼らず、コマンドで証明書を確認できます。LinuxやmacOSのターミナル、Windowsなら WSL や Git Bash で実行できます。example.com は自分のドメインに読み替えてください。
証明書の期限・発行元・対象ドメインを確認する
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltNamenotAfter:有効期限の終わり。これが過去なら期限切れです。issuer:発行元のCA。Subject Alternative Name:証明書が有効なドメイン名の一覧。アクセスするドメイン(wwwの有無も)が含まれているか確認します。
-servername は、1つのIPアドレスに複数のサイトを置く環境で正しい証明書を引き出すために必要です。-ext オプションはOpenSSL 1.1.1以降で使えます。
30日以内に切れるかどうかを判定する
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -checkend 25920002592000は30日分の秒数です。30日以内に切れるなら「Certificate will expire」、そうでなければ「Certificate will not expire」と表示されます。この結果を終了コードで判定して、監視用のスクリプトに組み込むこともできます。
中間証明書が送られているか(チェーン)を確認する
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null出力の「Certificate chain」に、サーバー証明書に続いて中間証明書が並んでいれば正常です。リーフ証明書1枚しかなく、末尾に「Verify return code: 21 (unable to verify the first certificate)」と出る場合は、中間証明書の不足が疑われます。正常なら「Verify return code: 0 (ok)」です。
curlで簡易確認する
curl -vI https://example.com 2>&1 | grep -iE 'expire|issuer|subject|SSL certificate'証明書に問題があれば、curlは「SSL certificate problem」などのエラーで失敗します(-k で検証を無効にすると失敗しなくなるため、確認時には付けないでください)。
certbotで証明書の自動更新を設定する
期限切れを防ぐ最も確実な方法は、自動更新を設定し、更新が本当に動くかをテストしておくことです。ここではLet's Encryptの公式クライアント certbot(EFFが提供)を使う例を示します。
インストールと証明書の取得(nginx・snap版)
certbot公式の手順では、Linuxにsnapでインストールします。
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot
sudo certbot --nginx -d example.com -d www.example.comwwwの有無の不一致を避けるため、-d を2つ指定しています。Apacheなら --apache を使います。証明書の取得だけで設定は自分で行うなら certbot certonly を使います。認証には、既定でHTTP-01方式が使われ、ポート80に外部から接続できる必要があります。ファイアウォールでポート80を閉じていると失敗します。
自動更新の仕組みと動作テスト
certbot公式は、システムに入るcertbotのパッケージには、期限前に自動更新を行うcronジョブまたはsystemdタイマーが付属すると説明しています。登録状況は次のコマンドで確認できます。
systemctl list-timers | grep -i certbot
sudo certbot certificates更新が正しく動くかは、本番の証明書を書き換えない模擬実行で確かめます。
sudo certbot renew --dry-run成功すれば「Congratulations, all simulated renewals succeeded」と表示されます。失敗する場合は、ポート80の遮断、サーバー設定の変更、DNS設定などを疑ってください。
更新後にWebサーバーへ反映させる
証明書ファイルが更新されても、Webサーバーが古い証明書をメモリに読み込んだままだと、期限切れの警告が出続けます。certbotにはデプロイフックがあり、更新に成功したときだけコマンドを実行できます。
sudo certbot renew --deploy-hook "systemctl reload nginx"snap版のcertbotは、nginx・Apacheのプラグインを使って取得した証明書では、通常は反映まで自動で行います。それでも、運用環境で確実に反映されているか、前章の openssl コマンドで実際の有効期限を確認する習慣をつけてください。
更新のタイミングと監視
Let's Encryptの公式ガイドは、更新の目安を「証明書の寿命の3分の1が残ったとき(90日証明書なら約30日前)」としています。Let's Encryptは、期限通知メールを2025年6月4日で終了しているため、自動更新が失敗したとき気づく仕組みが別に要ります。前章の -checkend を使った定期チェックや、外部の証明書監視サービスの利用を検討してください。
サーバー情報調査で証明書の状態を確認する
サイトスカウターの「サーバー情報調査」(/server/)にドメインを入力すると、そのサイトのHTTPS対応の有無と証明書の状態を確認できます。コマンドを使わずに、運営者以外の第三者の視点で確認したいときに便利です。
- 証明書が期限切れか、自己署名か、アクセス先のドメインが証明書に含まれているか、の3点を判定します。
- 期限が30日未満になると警告として表示します。
- 発行者、有効期間、対象ドメイン(SAN)、証明書の認証レベル(DV・OV・EV・IV)なども表示します。
一方で、中間証明書の不足を直接診断する機能はありません。端末によって警告が出たり出なかったりするときは、前章の openssl s_client -showcerts でチェーンを確認してください。
調査は、TLSハンドシェイク1回やHTTP GET 1回といった、第三者のサーバーに負担をかけない範囲に限定しています。自分が運営するサイトの定期点検にご利用ください。
よくある質問
「詳細設定」から続行しても大丈夫ですか?
おすすめしません。続行すると、通信内容が第三者に見られたり書き換えられたりする恐れがあります。ログインや決済のあるサイト、公共Wi-Fiでは特に避け、運営者に連絡してください。
自分のPCだけでエラーが出ます。何を確認すればよいですか?
まずPCの日時と時刻が正しいか、日時の自動設定がオンかを確認してください。次に別の回線(モバイル回線など)で試し、セキュリティソフトのHTTPS検査機能や、Chromeの拡張機能の影響も確認します。
SSL証明書が期限切れになると、どうなりますか?
サイトへのアクセス時に、Chromeなどのブラウザーが警告を表示し、多くの訪問者が離脱します。証明書を更新し、Webサーバーに反映すれば直ります。Let's Encryptの証明書は既定で90日有効なので、自動更新の設定が必須です。
wwwなしでは開けるのに、wwwありだと警告が出るのはなぜですか?
証明書に記載されたドメイン名に www.example.com が含まれていないためです。証明書を再取得する際に、example.com と www.example.com の両方を指定してください。
パソコンでは開けるのに、スマートフォンだけ警告が出ます。
サーバーが中間証明書を送っていない可能性があります。PCのブラウザーは補完できても、スマートフォンのブラウザーやアプリでは補完できないことがあります。fullchain.pem を設定してください。
出典・参考資料
最終確認日:2026-10-06。制度・仕様は変更されることがあるため、実施前に各一次情報をご確認ください。
- サイトの接続が安全かどうかを確認する - Google Chrome ヘルプ
- Chrome の接続エラーと読み込みエラーを解決する - Google Chrome ヘルプ
- Let's Encrypt FAQ(証明書の有効期間と更新の推奨)
- Let's Encrypt Integration Guide(中間証明書・更新タイミング)
- Let's Encrypt Challenge Types(HTTP-01・DNS-01)
- Ending Support for Expiration Notification Emails - Let's Encrypt
- Certbot Instructions(nginx・snap)- EFF