同じIPに次の構成の2つのサイトがあります。
https://site2WithSSL.com および http://site1.com問題なくアクセスできます。この問題は、誰かがhttps://site1.comにアクセスしたいときに発生し、nginxはsite2WithSSL.comで応答します。これは避けたいと思います。つまり、誰かがhttps://site1.comにアクセスするときはいつでも、コンテンツを返す必要はなく、httpsにリダイレクトするだけです。 ://
構成は次のとおりです。
server {
listen 80;
server_name *.site1.com;
// ...
}
server {
server_name www.site2WithSSL.com;
return 301 $scheme://site2WithSSL.com$request_uri;
}
server {
listen 80;
listen 443 ssl;
server_name site2WithSSL.com;
ssl_certificate site2WithSSL.crt;
ssl_certificate_key site2WithSSL.key;
// ...
}
解決済み:サイトごとに異なるIPを使用
問題は、SSLが同じIP上の複数のvhostをサポートしていないことです。
NGINXがHTTP/1.1を介して新しい接続を受信すると、リクエストには、提供する仮想ホストを指定するHostヘッダーが含まれます(これは1.1での大きな変更であり、現在のように仮想ホストを許可します)。
ただし、HTTPSを使用すると、ヘッダーは暗号化され、復号化する前にキー交換とTLSレイヤーを確立する必要があります。つまり、SSL証明書が送信されるまで、nginxが適切なSSLサーバーブロックを選択する方法はありません。
Site2の構成の下にsite1のドメイン名に一致するリダイレクトを追加することもできますが、それでもユーザーは証明書が無効であるというメッセージを受け取るため、あまり口に合いません。
費用はかかりますが、使用できるマルチドメイン証明書がいくつかあります。
最も簡単で、希望する構成では、おそらく最良のオプションは、サイトごとに異なるIPアドレスを使用することです。さまざまなNGINXサーバー構成がさまざまなアドレスにバインドできるため、どちらがどれであるかについての質問はありません。ほとんどのプロバイダーは、複数のIPアドレス、場合によっては複数のブロックを提供できます。もちろん、クラウドではさらにプロビジョニングすることができます。
更新:SNIは、暗号化されたペイロードの外にHostヘッダーを移動することでこの問題を回避し、最新のブラウザーでサポートされています。
クライアントがSSLクライアントHelloからどのサイトを取得したいかしかわからないため、1つのサイトだけで同じIPのポート443でリッスンすることはできません。 Helloを受信した後、SSLハンドシェイクを完了するか、接続を切断するかを選択できます。前者の場合は証明書を提供する必要があり、後者の場合、クライアントはSSL接続の切断について役に立たないエラーを受け取ります。
最後に、それは次のオプションに要約されます。
最後のオプションのみが、クライアントでエラーなしで機能します。
http://site1.com にのみリダイレクトするSSLなしでポート443でリッスンするsite1.comの構成について考えていました。新しいIPアドレスがなくても動作するはずだと思います。