web-dev-qa-db-ja.com

http経由でポート443を提供すると、リダイレクトではなく400 Bad Requestエラーが発生する

後世のために、誰かがhttp：// domain.com:443にアクセスしようとしても、httpsバージョンのサイト（https：//に正しくリダイレ​​クトされるようにサーバーを構成しようとしています。 domain.com）。

Http：// domain.com:443のようなものをテストすると、https：// domain.comに正しくリダイレ​​クトされず、代わりに次の内容の400 Bad Requestページが表示されます。

要求の形式が正しくありません

あなたのブラウザはこのサーバーが理解できないリクエストを送信しました。理由：SSL対応のサーバーポートにプレーンHTTPを話している。代わりに、HTTPSスキームを使用してこのURLにアクセスしてください。

Apache.2.4.18（Ubuntu）サーバー（sub.domain.comポート443）

000-default.confの<VirtualHost *:80>に次の行を含めてみました。

RewriteEngine On 
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{SERVER_NAME}/$1 [R,L]

しかし、それはうまくいきませんでした。

この問題は、すべてのドメイン、サブドメイン、およびサーバーIP自体で発生します。

おそらく関連しており、letsencryptの予行演習を実行しようとすると、次の結果が返されます。

   Domain: domain.com
   Type:   connection
   Detail: Failed to connect to 123.123.123.123:443 for TLS-SNI-01
   challenge

サイトが有効なフォルダにリストされているすべてのドメイン。

sslapache-2.4http
6
Bitz

TL; TR：同じポート（443）でHTTPとHTTPSの両方を提供することはできません。

理論的には、クライアントがHTTPリクエスト（つまりGET ..または類似のもの）を送信しているか、TLSハンドシェイク（\x16\x03...）を開始しているかどうか、クライアントからの最初のデータに基づいて把握することは可能です。 Webサーバーはこれを行いません。代わりに、クライアントが正常に動作することを期待しています。つまり、あるポート（通常は80）でプレーンHTTPを使用し、別のポート（通常は443）でHTTPSを使用します。

http://example.com:443のURLにより、ブラウザはポート443にプレーンHTTPリクエストを送信します。ただし、サーバーはTLSを期待しているため、プレーンHTTPリクエストは予期されていません。この場合、Apacheは少なくともプレーンなHTTPリクエストの受信データをチェックできるので、より有用な説明を提供できます。

理由：SSL対応のサーバーポートにプレーンHTTPを話している。代わりに、HTTPSスキームを使用してこのURLにアクセスしてください。

他のサーバーでこのような要求を試みると、クライアントからTLSハンドシェイクを取得することを望んでいるため、エラーなしで接続を閉じるか、単にハングアップします。

10
Steffen Ullrich

私はこれと同じエラーがあり、原因は私の設定が私の非SSLポートでSSLを有効にしようとしたことでした。 http://で始まるWebサイトアドレスはすべてポート80（<VirtualHost *:80>）経由で送信され、そのホストはSSLについて何も知りたくありません。 https://で始まるサイトはすべて、ポート443（<VirtualHost *:443>）を介してファネリングされます

より直接的な問題は、*:80ホストの下に次のSSL詳細があり、Apacheが非SSL接続でSSLを有効にしようとしたことです。

SSLEngine on
SSLCertificateFile /bla.crt
SSLCertificateKeyFile /bla.key
SSLCertificateChainFile /bla.crt

*:80からこれらの行を削除した後（およびそれらが<VirtualHost *:443>の下にあることを確認した後）、サーバーが再びポップアップしました。

だから、これが私の<VirtualHost>sです（すべて/etc/Apache2/sites-available/http.confですが、設定によって異なる場合があります）：

<VirtualHost *:80>

    -- snip --

    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_Host}%{REQUEST_URI} [R,L]

</VirtualHost>


<VirtualHost *:443>

    -- snip --

    SSLEngine on
    SSLCertificateFile /var/www/ssl/STAR_iconcierge_net_au.crt
    SSLCertificateKeyFile /var/www/ssl/STAR_iconcierge_net_au.key
    SSLCertificateChainFile /var/www/ssl/STAR_iconcierge_net_au.crt

</VirtualHost>

*:80（http）が*:443（https）への書き換えを実行し、SSLEngine onディレクティブを使用してSSLを適用する方法に注意してください。

3
Abraham Brookes

実際に監視しているのは、WebサーバーからユーザーにHSTSヘッダーを送信することです。これにより、ブラウザーは常にTLSを使用してサイトにアクセスするように指示されます。どのブラウザの開発ツールからもわかるように、ここでは_301_リダイレクトは発生していません。

これは、たとえばGoogleで発生します。初めてGoogleにアクセスすると、HSTSヘッダーが送信され、ブラウザーはそのヘッダーをリストに保存しました。その後、_google.com_を使用して_http://_に接続しようとすると、リモートWebサーバーと通信せずに、ブラウザが接続方法を自動的に_https://_に変更します。

これは、セキュリティ層への攻撃を防ぐためのセキュリティメカニズムの1つです。

2
Tero Kilkanen

ポート443を使用してサイトにアクセスする場合、<VirtualHost *:80>セクション内にあるものは何も処理されません。

Apache2に付属するデフォルトサイトのsslバージョンを有効にすることをテストし、<VirtualHost *:443>内でそのconfを試してください

0
canciobello