web-dev-qa-db-ja.com

Apache上の特定の仮想ホストのSNIを無効にする

いくつかのインターネットIPを備えたWebサーバーがあります。

私はSNI名ベースの仮想ホストを正常にセットアップしました。私がやりたいのは、メインサイトでSNIを使用せず、一意のIPアドレスの1つだけを使用することです。これにより、そのサイトのブラウザーサポートが改善されます（XP/IEの組み合わせ）。

私たちは非常に人気のあるサイトを運営しており、かなり古いユーザーがかなり古いブラウザを実行しているため、非常に重要です。

CentOS 6でのApache 2.2（2.2.15-47.el6_7）の実行。

apache-2.2sslsni
5
John Hunt

他の人が述べたように、最初のサイトを最初の仮想ホストとして配置するだけで、SNIが有効かどうかに関係なく機能します。

<VirtualHost *:443>

   ServerName www.site1.com

   DocumentRoot /site1/

   SSLCertificateKeyFile /ssl/server1.key
   SSLCertificateFile /ssl/server1.crt

</VirtualHost>

<VirtualHost *:443>

   ServerName www.site2.com

   DocumentRoot /site2/

   SSLCertificateKeyFile /ssl/server2.key
   SSLCertificateFile /ssl/server2.crt

</VirtualHost>

ただし、サイト2への非SNIブラウザーにはサイト1の証明書が提供されるため、エラーが発生します（そして、ユーザーはなぜ別のサイトの証明書を取得したのか疑問に思うかもしれませんが、非SNIブラウザーではまだそうではありませんハイテクに精通している）。

ただし、明らかなSNIの問題があっても、サイトのサブジェクトの別名をすべてカバーする単一の証明書がある場合は、サイトにallユーザーにallのアクセスを提供することが可能です。フィールド。

その後、同じキーと証明書を使用して2つの仮想ホストを作成できます。

<VirtualHost *:443>

   ServerName www.site1.com

   DocumentRoot /site1/

   SSLCertificateKeyFile /ssl/server.key
   SSLCertificateFile /ssl/server.crt

</VirtualHost>

<VirtualHost *:443>

   ServerName www.site2.com

   DocumentRoot /site2/

   SSLCertificateKeyFile /ssl/server.key
   SSLCertificateFile /ssl/server.crt

</VirtualHost>

したがって、2つのサイト（または必要に応じて3つ以上）で同じキーと証明書を使用します。

したがって、www.site1.comは常に機能します。SNIのサポートがなくても、デフォルトのホストとして機能します。

Www.site2.comの場合、より興味深いものになります。

  • SNIをサポートするブラウザーの場合、サーバー名を提供し、直接site2仮想ホスト構成に移動すれば機能します。
  • SNIをサポートしないブラウザーの場合、デフォルトでsite1構成になり、証明書が返されますが、証明書は両方のサイトで機能するため、実際には問題ありません。 SSLネゴシエーションが完了すると、最初のWeb要求が受信されますが、今回はサーバーにサーバー名が付けられているため、/ site2 /ディレクトリからドキュメントを正しく提供できます。

つまり、https接続には2つの異なる関連のない手順が含まれているため、これは機能します。1）SSLネゴシエーションを実行し、2）そのSSL接続を使用してドキュメントを要求します。 ）。

このオプションの主な欠点は、Webサイトの関連性の程度によっては、同じ証明書に2つの異なるURLを設定するのは専門的でないように見える場合があることです。ただし、おそらくそれらがホストを共有している場合、それらはいくぶん関連するビジネスであるため（サーバーがホスティング会社によって所有されている場合を除く）、これは問題ではない可能性があります。

これは、特に1つのIPアドレスで複数のサイトをホストし、サブジェクトの別名フィールドに複数のURLを使用した自己署名セントを使用する開発サーバーの場合、便利な小さな回避策です。

6
Barry Pollard

サーバー側でSNIを「無効」にしないでください。クライアントが拡張機能を送信するかどうかを制御することもできません。できることは、サーバーがSNI情報の存在（または不在）に応答する方法を定義することだけです。

通常、サーバーはSNI情報のない要求を受信すると、クライアントに提示できる証明書の1つを選択します。 Apacheの場合は、リッスンされているアドレス/ポートのペアの最初の仮想ホストになります。

SNIがなくても安全にアクセスできるようにしたいサイトに個別の「非SNI」アドレスを設定するかどうかについては、重要ではないと思います。貴重なIPv4アドレスを保存して、それらすべてを同じIPに配置することもできます。非SNIブラウザーからSNI専用サイトにアクセスするユーザーは、非SNIサイトと同じアドレスかどうかに関係なく、とにかく同じ証明書の警告を受け取ります。唯一の考慮事項は、非SNIクライアントをサポートするサイトの証明書が、SNI専用サイトにアクセスするときに非SNIクライアントに提示されるかどうかです。

「SNI」と何度も入力したので、すべての意味が失われ始めています...

2
womble