このエラーの実際の意味
HTTPS経由でサイトを読み込もうとしていますが、Firefoxが問題に直面し、安全な接続に失敗したことを表示しています。具体的には、SSL_ERROR_RX_RECORD_TOO_LONG というコードが表示されます。これは標準的な「証明書の期限切れ」の警告ではなく、根本的なプロトコルの不一致を意味します。ブラウザとサーバーが同じ言語で通信できていないため、この画面には「リスクを承知で続行」といったボタンは表示されません。
根本的な原因：HTTP vs. HTTPS
このエラーは、Firefoxが暗号化されたTLSハンドシェイクを期待しているのに、代わりに暗号化されていないプレーンなHTTPレスポンスを受け取ったときに発生します。通常、サーバーがポート443でリッスンしているものの、その特定のポートでSSL/TLSを使用するように設定されていない場合に起こります。
なぜ「record too long（レコードが長すぎる）」という表現なのでしょうか？標準的なTLSレコードの最大長は16,384バイト（16 KB）です。Firefoxが接続すると、「Client Hello」を送信します。もしサーバーが HTTP/1.1 404 Not Found のようなプレーンテキストで応答すると、Firefoxはその最初の数文字のASCII文字をバイナリの長さフィールドとして解釈しようとします。その結果、算出される数値が膨大になり、16 KBの制限を大幅に超えてしまうため、ブラウザは安全のために接続を強制終了します。
解決策1：Nginxの設定を修正する
Nginxを運用しているサーバー管理者の場合、listen ディレクティブで ssl パラメータを省略していることが原因であることが多いです。もし設定が以下のスニペットのようになっているなら、それが原因です：
server {
listen 443;
server_name example.com;
# エラー：ポート443は開いているが、SSLが有効になっていない
}
これを修正するには、listenの行に ssl を追加し、証明書のパスを定義します。最近の設定では、脆弱な古いプロトコルを避けるためにTLSバージョンも指定する必要があります：
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# セキュリティ向上のためTLS 1.2と1.3を使用する
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
}
ターミナルを閉じる前に、構文を確認してサービスを再読み込みしてください：
sudo nginx -t
sudo systemctl reload nginx
解決策2：ApacheのVirtualHostを修正する
Apacheユーザーの場合、ポート443のブロック内で SSLEngine がオフになっているとこの問題が発生します。有効な証明書がリンクされていても、明示的に暗号化をオンにしない限り、Apacheはデフォルトでプレーンテキストを使用します。
設定ファイル（通常は /etc/apache2/sites-available/ 内）で以下の行を確認してください：
<VirtualHost *:443>
ServerName example.com
SSLEngine on
SSLCertificateFile /etc/ssl/certs/example.pem
SSLCertificateKeyFile /etc/ssl/private/example.key
</VirtualHost>
新しい証明書をインストールしたばかりの場合は、SSLモジュールが実際に動作しているか確認してください。念のため以下のコマンドを実行します：
sudo a2enmod ssl
sudo a2ensite your-ssl-config.conf
sudo systemctl restart apache2
解決策3：Cloudflareプロキシの不一致を解消する
トラフィックがCloudflareや同様のCDNを経由している場合、このエラーは多くの場合「SSL終端」のループに起因します。これは、プロキシがあるプロトコルを期待しているのに、オリジンサーバーが別のプロトコルを提供している場合に発生します。
- **Flexible SSLの罠：** 「Flexible」モードでは、Cloudflareはポート80（HTTP）経由でサーバーに接続します。サーバーがポート443への強制リダイレクトを設定しているにもかかわらず、そのポートでSSLが設定されていない場合、ハンドシェイクは失敗します。
- **Full/Strictモード：** これが推奨される設定です。オリジンサーバーに有効な証明書（「Full」モードの場合は自己署名証明書でも可）があり、実際の暗号化を使用してポート443で通信する必要があります。
Cloudflareの設定を Full または Full (strict) に切り替えてください。その後、オリジンサーバーが誤ってポート443でプレーンなHTTPを提供していないか確認します。
解決策4：ローカルブラウザのトラブルシューティング
ChromeやSafariではサイトが表示されるのに、Firefoxで失敗しますか？その場合は、ローカルキャッシュの不具合や、ブラウザ内のプロキシ設定の競合が原因かもしれません。
- **ハードリフレッシュを強制する：** `Ctrl + F5`（Macの場合は `Cmd + Shift + R`）を押して、ローカルキャッシュをバイパスします。
- **Firefoxのプロキシ設定を確認する：** **設定** > **ネットワーク設定** に移動します。環境で特別に必要とされていない限り、「プロキシなし」に設定されていることを確認してください。
- **スタートアップキャッシュをリセットする：** アドレスバーに `about:support` と入力し、**スタートアップキャッシュを消去...** を選択して、一時的なアーキテクチャデータを削除します。
修正を確認する方法
ブラウザの結果だけに頼らず、curl を使用してサーバーが実際に何を返しているかを確認してください。ターミナルで以下のコマンドを実行します：
curl -vI https://yourdomain.com
* SSL connection using TLSv1.3 という行を探してください。もし Received HTTP/0.9 when not allowed と表示される場合は、サーバーは依然として暗号化ポートでプレーンテキストを出力しています。ハンドシェイクが正常に完了すれば、Firefoxのエラーはすぐに解消されるはずです。