ERR_SSL_PROTOCOL_ERROR

結論

ERR_SSL_PROTOCOL_ERRORは、ブラウザがサーバーとのTLSハンドシェイクを完了できなかったことを意味します。よくある原因には、port 443での平文HTTP、誤ったHTTPS仮想ホスト、CDNまたはプロキシの不一致、互換性のないTLS設定などがあります。ブラウザ設定を変更する前に、サーバー側またはネットワーク側からHTTPSエンドポイントと証明書をテストしてください。

要点

まず、port 443がTLSを処理しているか確認します。このポートで平文HTTPレスポンスや別のプロトコルが返されると、このエラーが発生することがよくあります。
証明書が存在していても、有効期限切れ、要求されたホスト名の不足、中間証明書の欠落、更新後に読み込まれていないなどの理由で使用できない場合があります。
CDN、リバースプロキシ、ロードバランサーの設定は、オリジンが実際に使用するHTTPSプロトコル、ポート、ホスト名、証明書の設定と一致している必要があります。
SNIを指定したopenssl s_clientを使い、リスナーの問題、証明書の選択、証明書チェーン、TLSポリシーの問題を切り分けます。
証明書の検証を恒久的に無効化しないでください。オリジンの証明書とTLS設定を修正します。

更新日: 2026-09-22 · 編集レビュー待ち SSLとセキュリティのエラー

Site Administrator

このエラーの意味と見分け方

ChromeまたはEdgeに「このサイトでは安全な接続を提供できません」と表示され、ERR_SSL_PROTOCOL_ERRORが報告される。
サイト全体、1つのサブドメイン、またはプロキシやロードバランサーの背後にある特定のホスト名だけに影響する場合があります。
port 80の平文HTTPは動作する一方でHTTPSだけが失敗することがあります。この場合、必ずしもアプリケーションではなく、TLS経路に問題があることを示します。
証明書の更新、サーバー移行、Webサーバー設定の変更、CDNの変更、port 443で待ち受けるサービスの変更後に発生し始めることがあります。
CDN、リバースプロキシ、ロードバランサーが関与している場合、オリジンへの直接テストと公開ホスト名のテストで結果が異なることがあります。

可能性の高い順の主な原因

port 443で平文HTTPまたは別の非TLSプロトコルを提供している。 HTTPSリスナーが存在しないか、別のサービスがport 443を使用している可能性があります。その場合、ブラウザはTLSハンドシェイクではないデータを受け取ります。
HTTPSの仮想ホストまたはserver blockが正しくない。 サーバーが誤ったアドレスで待ち受けている、誤ったホスト名を選択している、またはWebサーバーに必要なTLSディレクティブが不足している可能性があります。
CDN、リバースプロキシ、またはロードバランサーでオリジン設定が一致していない。 プロキシがHTTPで接続しているのにオリジンがHTTPSを要求している、または誤ったポートやバックエンドに接続している可能性があります。
TLS設定に互換性がない、または不正な状態になっている。 サポートされていないプロトコルバージョン、厳しすぎる暗号スイート設定、SNIルーティングの問題、TLS終端デバイスの設定ミスにより、証明書の検証前にハンドシェイクが停止することがあります。
証明書または証明書チェーンが使用できない。 期限切れの証明書、中間証明書の欠落、要求されたホスト名をカバーしていない証明書により、安全な接続を確立できないことがあります。一部のブラウザや接続経路では、より具体的な証明書警告が表示される場合もあります。
更新した証明書がサービスに読み込まれていない。 ディスク上の証明書ファイルを更新しただけでは、実行中のWebサーバーが提示する証明書は変わりません。サービスの文書化された手順に従って設定をリロードまたは再起動する必要があります。

修正方法

Diagnostic flow at a glance — full detail in the steps below.

1. 失敗が公開環境、オリジン固有、ローカルのいずれかを確認する

別のネットワークまたはデバイスから、失敗している正確なホスト名を試します。1台のコンピューターだけで失敗する場合は、ローカルのセキュリティソフト、インターセプトプロキシ、システム時刻を確認します。すべてのクライアントで失敗する場合は、サーバー、プロキシ、CDN、ロードバランサーを調査します。

HTTPは動作するのにHTTPSが動作しない場合は、TLSリスナー、port 443、証明書の選択、クライアントとオリジンの間にあるプロキシに注目します。HTTPが成功したからといって、HTTPS設定が正しいとは限りません。

2. サーバーの状態を変更せずにTLSハンドシェイクをテストする

エンドポイントへのネットワークアクセスが可能な管理用ターミナルから、次を実行します。

text

openssl s_client -connect [your-hostname]:443 -servername [your-hostname] -showcerts

SNIによって証明書や仮想ホストが選択される場合、-servernameオプションが重要です。ハンドシェイクが開始するか、どの証明書が返されるか、証明書の有効期限、Subject Alternative Nameに記載されたホスト名、中間証明書が含まれているかを記録します。

接続時に平文HTTPが返される、または証明書が表示される前に失敗する場合は、port 443のリスナーとプロキシのルーティングを調べます。
証明書が返される場合は、要求したホスト名と一致するか、有効期間と証明書チェーンを確認します。
オリジンへの直接テストは成功するのに公開ホスト名が失敗する場合は、アプリケーションを変更せず、CDN、リバースプロキシ、ロードバランサー、DNS経路を調べます。

3. HTTPSリスナーとホスト名ルーティングを確認する

適切なサーバーアクセス権限と認可を得たうえで、アクティブなWebサーバー設定を調べ、次を確認します。

意図したサービスがport 443で待ち受けていること。
HTTPSのserver blockまたは仮想ホストが有効になっていること。
要求されたホスト名が、該当するserver_nameまたはServerName/ServerAlias設定に含まれていること。
そのリスナーでTLSが有効になっていること。
証明書と秘密鍵のパスが意図したファイルを指していること。

Nginxでは、有効化されたserver blockとlisten 443 ssl設定を確認します。Apacheでは、<VirtualHost *:443>設定とSSLEngine onを確認します。インストールされているサーバーがサポートする構文とバージョンを確認せずに、製品間でディレクティブをコピーしないでください。

4. 証明書と証明書チェーンを検証する

提示された証明書について、次を確認します。

有効期限切れまたは有効期間開始前ではないこと。
Subject Alternative Nameのエントリに、正確なホスト名が含まれていること。
対応する秘密鍵と一致すること。
必要な中間証明書チェーンが付属していること。

ベアドメイン用の証明書が、すべてのサブドメインを自動的にカバーするわけではありません。サブドメインは明示的に記載されているか、適切なワイルドカード証明書でカバーされている必要があります。サーバーがリーフ証明書だけを提示している場合は、認証局が提供するチェーンファイルを、Webサーバーが要求する形式でインストールします。

5. 更新と証明書の読み込みを確認する

Certbotで管理する構成では、管理者がcertbot renew --dry-runを実行して、本番用証明書を発行せずに更新ワークフローをテストできます。出力、更新設定、権限、サービスのreload hookを確認します。

更新が成功したのにクライアントが古い証明書を受け取る場合は、WebサーバーまたはTLS終端プロキシが新しいファイルを読み込んでいることを確認します。リロードまたは再起動はサービスの状態を変更するため、ロールバック計画と製品の文書化された手順を用意し、承認済みのメンテナンス時間内にのみ実施してください。この運用操作は、読み取り専用の診断とは分けて扱います。

6. CDN、プロキシ、ロードバランサーのTLS設定を調べる

TLSがどこで終端しているかを特定します。CDN、エッジプロキシ、ロードバランサー、オリジンサーバーのいずれかです。設定されたオリジンのプロトコルとポートが、オリジンが実際に提供しているものと一致することを確認します。

CDNにFlexible、Full、Full (strict)などのモードがある場合は、オリジンの実際の設定と証明書の有効性に一致するモードを選択します。より厳格でないモードは根本的な問題を隠したり、別の障害を発生させたりする可能性があり、有効なオリジン証明書の恒久的な代替にはなりません。設定変更は認可を得て行い、可能な場合は公開ホスト名とオリジン経路の両方を再テストします。

7. プロトコル、SNI、ネットワーク機器による干渉を確認する

エンドポイントが一致する有効な証明書を提示しているのにハンドシェイクが失敗する場合は、異なるネットワークとTLSクライアントで結果を比較します。ファイアウォール、ロードバランサー、Webアプリケーションファイアウォール、TLSインスペクションの設定を確認し、プロトコルバージョンのブロック、サポートされない暗号ポリシー、誤ったSNIルーティング、トラフィックの変更がないか調べます。ホスティングプロバイダーまたはネットワーク管理者に渡せるよう、ハンドシェイクの出力と関連するサーバーログを保存します。

予防と修正確認

更新メカニズムとは独立して証明書の有効期限を監視し、証明書が無効になる前にアラートを設定します。
非本番環境またはdry-runワークフローで更新をテストし、サービスのreload hookが実際に新しい証明書を提示することを確認します。
すべてのホスト名、TLS終端ポイント、証明書、秘密鍵、中間証明書チェーンを文書化した一覧で管理します。
証明書、プロキシ、ロードバランサー、ポートマッピングを変更した後は、公開ホスト名と重要な各サブドメインをテストします。
デプロイ前に、SNI、プロトコルバージョン、暗号、オリジンポートの互換性についてTLS設定の変更を確認します。
ハンドシェイクが失敗した際に、直近の正常な設定と比較できるよう、最近のサーバー、プロキシ、証明書の情報を保持します。

外部の助けが必要なタイミング

エンドポイントが一致する有効な証明書と完全な証明書チェーンを返しているのにハンドシェイクが失敗する場合は、ホスティングプロバイダー、CDN、ロードバランサー管理者、またはネットワークチームにエスカレーションします。正確なホスト名、失敗した時刻、テストが直接接続かプロキシ経由か、openssl s_clientの結果、関連するWebサーバーまたはプロキシのログ、最近の設定変更を含めてください。秘密鍵などの機密情報は共有しないでください。

どのサービスがTLSを終端しているか特定できない場合や、証明書の変更、リロード、再起動にプロバイダー側のアクセスが必要な場合も、エスカレーションが適切です。再起動やリロードは、プロバイダーが承認したメンテナンスおよびロールバック手順の範囲内で行ってください。

Webサイトを確認

よくある質問

ERR_SSL_PROTOCOL_ERRORは期限切れの証明書が原因ですか？

証明書の有効性が関係している可能性はありますが、期限切れの証明書では、通常は証明書固有の警告が表示されます。ブラウザのエラーが証明書の具体的な問題を特定していると決めつけず、ハンドシェイク全体の結果を確認してください。

HTTPは動作するのに、HTTPSでERR_SSL_PROTOCOL_ERRORが表示されるのはなぜですか？

通常、HTTPとHTTPSは異なるポートとリスナーを使用します。HTTPは動作するのにHTTPSが失敗する場合、アプリケーションは正常でも、port 443のHTTPS設定がない、誤ったサービスが動作している、またはプロキシとオリジン間のTLSに問題がある可能性があります。

このエラーについてopenssl s_clientで何が分かりますか？

TLSハンドシェイクが開始するか、エンドポイントがどの証明書を提示するか、SNIによって期待した証明書が選択されるか、どの証明書チェーンが返されるかを確認できます。これにより、非TLSリスナーの問題と、証明書、証明書チェーン、TLSポリシーの問題を切り分けられます。

メインドメイン用の証明書でサブドメインもカバーできますか？

自動的にはカバーできません。要求されたサブドメインが証明書のSubject Alternative Namesに含まれているか、適切なワイルドカードエントリでカバーされている必要があります。ベアドメインだけをカバーする証明書では、すべてのサブドメインに対して十分ではありません。

CloudflareなどのCDNを使っている場合、このエラーをどう調査しますか？

エラーがブラウザとCDNの間で発生しているのか、CDNとオリジンの間で発生しているのかを確認します。設定されたオリジンのホスト名、ポート、プロトコル、証明書の有効性、検証モードを確認します。証明書の検証を恒久的に弱めるのではなく、オリジンの設定を修正してください。

更新後も古い証明書が表示されるのはなぜですか？

更新処理によって新しい証明書がディスクに書き込まれても、TLSを終端するサービスがリロードされていない可能性があります。認可されたリロードまたは再起動を行う前に、アクティブなエンドポイントが提示する証明書を確認し、サービスのreload hookを調べてください。