web-dev-qa-db-ja.com

Apache SNI namevhostsは常に最初のVirtualHostエントリにルーティングします

Apacheは、ServerName/ServerAliasフィールドでのSNIの一致に関係なく、すべてのhttpsリクエストを最初の_<VirtualHost *:443>_にルーティングするようです。

ApacheはSNIで構築されています
サーバーバージョン：Apache/2.2.22（Ubuntu）
サーバー構築：2013年3月8日15:53:13
OpenSSL 1.0.1 2012年3月14日

error.logレポート：

_Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
_

これは、SNIが次のように機能していることを示唆しています http://wiki.Apache.org/httpd/NameBasedSSLVHostsWithSNI （ApacheビルドがSNIをサポートしているかどうかを確認するにはどうすればよいですか？）

_SSL_TLS_SNI_はHTTPSを使用して要求されたときに適切に設定されているようです（phpinfo()で検証済み）

構成：

_<IfModule mod_ssl.c>
    # If you add NameVirtualHost *:443 here, you will also have to change
    # the VirtualHost statement in /etc/Apache2/sites-available/default-ssl
    # to <VirtualHost *:443>
    # Server Name Indication for SSL named virtual hosts is currently not
    # supported by MSIE on Windows XP.
    NameVirtualHost *:443
    Listen 443
</IfModule>

#<VirtualHost *:443>
#       <Location />
#               Order allow,deny
#               Deny from all
#       </Location>
#</VirtualHost>

<VirtualHost *:443>
        SSLEngine on
        ServerAdmin webmaster@localhost
        ServerName server.com
        ServerAlias server.com
        DocumentRoot /web/default
        ErrorLog ${Apache_LOG_DIR}/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${Apache_LOG_DIR}/access.log combined

        SSLCertificateFile /path/server.com.crt
        SSLCertificateKeyFile /path/server.com.key
</VirtualHost>
<VirtualHost *:443>
        SSLEngine on
        ServerAdmin webmaster@localhost
        ServerName alias.com
        ServerAlias alias.com
        DocumentRoot /web/default
        ErrorLog ${Apache_LOG_DIR}/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${Apache_LOG_DIR}/access.log combined

        SSLCertificateFile /path/alias.com.crt
        SSLCertificateKeyFile /path/alias.com.key
</VirtualHost>
_

https://server.com と https://alias.com の両方がserver.comから証明書（および証明書の警告を無視する場合はコンテンツ）を提供しようとします

HTTP：80を使用した同様の構成は正常に機能します（変更はSSLEngineと証明書/キーのパスのみです）

最初の仮想ホストのコメントを外すと（定義されているサイトへのHTTPSアクセスが制限されます）、常に（定義されたサイトであっても）SSLエラーが発生します。

ありがとう

編集：
追加のフラグ

_SSLProtocol all
SSLCipherSuite HIGH:MEDIUM
SSLStrictSNIVHostCheck on
SSLVerifyClient none
SSLProxyEngine off
_

_SSLStrictSNIVHostCheck on_なので、SNI対応のブラウザのみをサポートする必要があります

_Apache2ctl -S_出力：

_*:443                  is a NameVirtualHost
         default server server.com (/etc/Apache2/sites-enabled/000-default:22)
         port 443 namevhost server.com (/etc/Apache2/sites-enabled/000-default:22)
         port 443 namevhost alias.com (/etc/Apache2/sites-enabled/000-default:39)
         port 443 namevhost other.com (/etc/Apache2/sites-enabled/other:22)
_
apache-2.2sninamevirtualhost
7
arcyqwerty

更新

奇妙な理由で、問題は解決したようです。
おそらく、それはある種の奇妙なキャッシュの問題か何かです（私はApache2ctl stop/start/restartおよびSudo service Apache2 stop/start/restart/reloadedを何度も繰り返し、サーバー上でローカルにテストを実行したほか、複数の異なるマシンを使用しています。

この質問を削除するか、参照として役立つ場合はそのままにしておいてください。
ご協力ありがとうございました。

4
arcyqwerty

構成は問題ありません。 SSLEngine Onディレクティブが含まれています。ログメッセージによると、問題はクライアント側にあるようです。

すべてのクライアントがSNIをサポートしているわけではありませんが、ほとんどのクライアントがサポートしています。これは、システム（Win XP thenでは機能しません）、またはブラウザー（バージョンは十分に新しいものである必要があります）では機能しません）でSSLネゴシエーションが行われた方法によって異なります。 SNIをサポートするブラウザのリスト 。すべてのクライアントがWebサイトにアクセスできるようにする必要がある場合、これらの古いバージョン（ブラウザまたはシステム）のため、SNIを使用できません。 ServerNameごとにIPが必要で、ServerName alias.comにはVirtualHost $ IP_alias：443を、ServerName server.comにはVirtualHost *：443の代わりにVirtualHost $ IP_server：443を使用します。

1
philippe

最初の仮想ホストでエラーが発生するのは、SSLEngine onディレクティブが含まれていないため、ApacheがSSLなしでHTTP応答を送信するためです。この種の機能が必要な場合は、Niceエラーを返すだけでも、デフォルトの仮想ホスト用に別のサイト（既存のドメインを再利用しない限り、別の証明書を使用する可能性があります）を設定する必要があります。

おそらく、証明書が実際に異なることを確認しますか？設定は正しいようです。

また、ポート443でリッスンしている他のVirtualHostセクションがないことを確認します。Apacheは、最も一致するセクションを選択します。つまり、接続が入ったアドレスに固有のものがあれば、そのエントリは優先。これはあなたの問題ではないと思います。

さらに、興味深い点として、ユーザー側から見ているのは、クライアントがほとんどの場合にSNIをサポートしていなかった場合にどうなるかです。

0
Falcon Momot