web-dev-qa-db-ja.com

同じIPアドレスと同じポート上の複数のSSLドメイン？

これは、同じIPで複数のSSL Webサイトをホストすることについての 標準的な質問 です。

各SSL証明書には独自の一意のIPアドレス/ポートの組み合わせが必要であるという印象を受けました。しかし 私が投稿した以前の質問への回答 は、この主張と矛盾しています。

その質問からの情報を使用して、同じIPアドレスとポート443で動作する複数のSSL証明書を取得することができました。同じサーバーには独自のIP /ポートが必要です。

私は何か間違ったことをしたのではないかと疑っています。この方法で複数のSSL証明書を使用できますか？

apache-2.2sslvirtualhostsni
109
John

追加のHTTP固有のRFCを含む、ApacheおよびSNIの最新情報については、 Apache Wiki を参照してください。

FYsI：「1つのIP上の複数の（異なる）SSL証明書」は、TLSアップグレードの魔法によってもたらされます。それは新しいApacheサーバー（2.2.x）とかなり最近のブラウザー（私の頭の上のバージョンを知らない）で動作します。

RFC 2817（HTTP/1.1内のTLSへのアップグレード）には詳細はありませんが、基本的には（大多数ではないにせよ）多くの人にとって機能します。
ただし、opensslのs_clientコマンド（または「十分に古い」ブラウザ）を使用すると、古いファンキーな動作を再現できます。

追加する編集：明らかにcurlは、opensslよりもここで何が起こっているかを示すことができます：

SSLv3

mikeg@flexo% curl -v -v -v -3 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: serialNumber=wq8O9mhOSp9fY9JcmaJUrFNWWrANURzJ; C=CA; 
              O=staging.bossystem.org; OU=GT07932874;
              OU=See www.rapidssl.com/resources/cps (c)10;
              OU=Domain Control Validated - RapidSSL(R);
              CN=staging.bossystem.org
*    start date: 2010-02-03 18:53:53 GMT
*    expire date: 2011-02-06 13:21:08 GMT
* SSL: certificate subject name 'staging.bossystem.org'
       does not match target Host name 'www.yummyskin.com'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'staging.bossystem.org'
does not match target Host name 'www.yummyskin.com'

TLSv1

mikeg@flexo% curl -v -v -v -1 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: C=CA; O=www.yummyskin.com; OU=GT13670640;
              OU=See www.rapidssl.com/resources/cps (c)09;
              OU=Domain Control Validated - RapidSSL(R);
              CN=www.yummyskin.com
*    start date: 2009-04-24 15:48:15 GMT
*    expire date: 2010-04-25 15:48:15 GMT
*    common name: www.yummyskin.com (matched)
*    issuer: C=US; O=Equifax Secure Inc.; CN=Equifax Secure Global eBusiness CA-1
*    SSL certificate verify ok.
68
voretaq7

はい、しかしいくつかの注意点があります。

これは、トランスポート層セキュリティの拡張であるサーバー名表示によって実現されます。

サーバー名表示とは何ですか？

サーバー名表示 （ RFC 6066 ;廃止 RFC 4366 、 RFC 3546 ）は Transport Layer Security これにより、クライアントはサーバーが到達しようとしているホストの名前をサーバーに伝えることができます。

SNIは仕様に従ってTLS 1.0以上と互換性がありますが、実装は異なる場合があります（以下を参照）。 SSLでは使用できないため、SNIを使用するには、接続でTLSをネゴシエートする必要があります（ RFC 4346付録E を参照）。これは通常、サポートされているソフトウェアで自動的に行われます。

なぜSNIが必要なのですか？

通常の [〜＃〜] http [〜＃〜] 接続では、ブラウザはHost:ヘッダーを使用して到達しようとしているサーバーのホスト名をサーバーに通知します。これにより、単一のIPアドレスのWebサーバーが複数のホスト名のコンテンツを提供できるようになります。これは、一般に 名前ベースの仮想ホスティング として知られています。

別の方法は、サービスを提供する各Webホスト名に一意のIPアドレスを割り当てることです。これは、IPアドレスがなくなり、保護対策が開始されることが広く知られる前の、Webのごく初期に一般的に行われていましたが、SSL仮想ホスト（SNIを使用していない）の場合もこの方法で行われます。

ホスト名を送信するこの方法では、接続がすでに確立されている必要があるため、SSL/TLS接続では機能しません。安全な接続が設定されるまでに、ウェブサーバー自体が安全な接続を設定しているため、ウェブサーバーはクライアントに提供するホスト名をすでに知っている必要があります。

SNIは、クライアントがTLSネゴシエーションの一部としてホスト名を送信するようにすることでこの問題を解決します。これにより、サーバーは、接続のサービスに使用する仮想ホストを認識しています。サーバーは、正しい仮想ホストの証明書と構成を使用できます。

別のIPアドレスを使用しないのはなぜですか？

HTTP Host:ヘッダーは、1990年代中頃に問題として認識されたIPv4アドレスの不足により、単一のIPアドレスから複数のWebホストを提供できるように定義されました。共有Webホスティング環境では、このように単一のIPアドレスを使用して数百の固有で無関係なWebサイトを提供でき、アドレススペースを節約できます。

共有ホスティング環境は、IPアドレススペースの最大の消費者が、一意のIPアドレスを持つ安全なWebサイトの必要性であることがわかり、IPv6への道のりの一時的な手段としてSNIの必要性を生み出しました。今日では、正当な理由なしに5つ（/ 29）のIPアドレスを取得することが困難な場合があり、多くの場合、展開が遅延します。

IPv6の登場により、このようなアドレス保護手法は不要になりました。単一のホストに、インターネット全体に含まれるよりも多くのIPv6アドレスを割り当てることができるためです。しかし、この手法は、将来にわたって、レガシーIPv4のサービスに使用される可能性があります。接続。

注意事項

一部のオペレーティングシステムとブラウザの組み合わせはSNIをサポートしていないため（以下を参照）、SNIの使用がすべての状況に適しているわけではありません。このようなシステムとブラウザの組み合わせをターゲットとするサイトは、SNIを無視して、各仮想ホストに一意のIPアドレスを引き続き使用する必要があります。

特に注意すべき点として、Windows上のInternet ExplorerのバージョンはありませんXPはSNIをサポートしています。この組み合わせは依然として重要です（しかし着実に減少しています。NetMarketShareによると2012年12月のインターネットトラフィックの約16％）。インターネットトラフィックの場合、SNIはこれらのユーザーをターゲットとするサイトには不適切です。

サポート

すべてではありませんが、多くの一般的に使用されているソフトウェアパッケージがSNIをサポートしています。

（このリストからの省略は、必ずしもサポートの不足を意味するわけではありません。つまり、入力できる量に制限があったか、検索で情報をすばやく見つけることができませんでした。ソフトウェアパッケージがリストにない場合は、検索その名前プラスsniは、サポートが存在するかどうか、およびそれを設定する方法を明らかにする必要があります。）

ライブラリサポート

ほとんどのパッケージは、SSL/TLSサポートを提供するために外部ライブラリに依存しています。

  • GNU TLS
  • JSSE（Oracle Java）7以降、 クライアントとしてのみ
  • libcurl 7.18.1以降
  • NSS 3.1.1以降
  • OpenSSL 0.9.8j以降
    • OpenSSL 0.9.8f以降、構成フラグ付き
  • Qt 4.8以降

サーバーサポート

人気のあるサーバーソフトウェアの最新バージョンはSNIをサポートしています。セットアップ手順はこれらのほとんどで利用できます：

クライアントサポート

最新のWebブラウザーとコマンドラインユーザーエージェントはSNIをサポートしています。

デスクトップ

  • Chrome 5以降
    • Windows XP上のChrome 6以降
  • Firefox 2以降
  • Windows Vista/Server 2008以降で実行されているInternet Explorer 7以降
    • Windows上のInternet Explorer XPはIEバージョンに関係なくSNIをサポートしません
  • Konqueror 4.7以降
  • Opera 8以降（機能するにはTLS 1.1が有効になっている必要がある場合があります）
  • Windows Vista/Server 2008以降、またはMac OS X 10.5.6以降のSafari 3.0

モバイル

  • 3.0 Honeycomb以降のAndroidブラウザ
  • iOS 4以降のiOS Safari
  • Windows Phone 7以降

コマンドライン

  • cURL 7.18.1以降
  • wget 1.14以上（ディストリビューションはSNIサポートのために patch をバックポートした可能性があります）

サポートなし

  • BlackBerryブラウザ
  • Windows XP上のInternet Explorer（すべてのバージョン）

（注：この回答の一部の情報は Wikipedia から取得されました。）

97
Michael Hampton

問題：

WebクライアントとWebサーバーがHTTPSを介して相互に通信する場合、最初に発生する必要があるのは、安全なハンドシェイクです。

このようなハンドシェイクの簡単な例を次に示します。

tls handshake

これがHTTPSでなくHTTPSの場合、クライアントが最初に送信するはずのものは次のようなものでした。

GET /index.html HTTP/1.1
Host: example.com

サーバーは、クライアントがアクセスしたいドメイン、つまりexample.comを正確に認識しているため、単一のIPアドレスで複数の仮想ホストが可能になりました。

HTTPSは異なります。前に言ったように、ハンドシェイクは他のすべての前に来ます。上記のハンドシェイクの3番目のステップ（証明書）を見ると、サーバーはハンドシェイクの一部として証明書をクライアントに提示する必要がありますが、クライアントがアクセスしようとしているドメイン名はわかりません。サーバーが持つ唯一のオプションは、毎回同じ証明書、つまりデフォルトの証明書を送信することです。

Webサーバーに仮想ホストを設定することもできますが、サーバーは常に各クライアントに同じ証明書を送信します。サーバーでexample.comとexample.orgの両方のWebサイトをホストしようとした場合、クライアントがHTTPS接続を要求すると、サーバーは常にexample.comの証明書を送信します。したがって、クライアントが確立されたHTTPS接続を介してexample.orgをリクエストすると、次のようになります。

enter image description here

この問題により、HTTPSを介して提供できるドメインの数が、IPアドレスごとに1つに制限されます。

解決策：

この問題を解決する最も簡単な方法は、クライアントがアクセスしたいドメインをサーバーに知らせることですハンドシェイク中。このようにして、サーバーは正しい証明書を提供できます。

これはまさに [〜＃〜] sni [〜＃〜] 、またはサーバー名表示が行うことです。

SNIを使用すると、クライアントは最初のメッセージの一部として、アクセスしたいサーバー名を送信します。これは、上のハンドシェイク図の「Client Hello」ステップです。

一部の古いWebブラウザーはSNIをサポートしていません。たとえば、WindowsではXPあり-​​ 単一バージョンのInternet Explorerではない SNIをサポートしています。使用するサーバー上のHTTPS経由でリソースにアクセスする場合SNI仮想ホストの場合、一般的な証明書が表示され、ブラウザに警告またはエラーが表示される場合があります。

enter image description here

ここでは、問題の背後にある原理と解決策を説明するために、物事を簡略化しました。より技術的な説明が必要な場合は、 wikipedia ページまたは RFC 6066 が出発点として役立ちます。また、SNIをサポートするサーバーとブラウザーの最新リストを wikipedia で見つけることもできます。

37
Kenny Rasschaert

http://wiki.Apache.org/httpd/NameBasedSSLVHostsWithSNI

クライアントブラウザーもSNIをサポートしている必要があります。これを行うブラウザは次のとおりです。

* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (with TLS 1.1 enabled)
* Internet Explorer 7.0 or later (on Vista, not XP)
* Google Chrome
* Safari 3.2.1 on Mac OS X 10.5.6
16
Craig

サーバー名表示（RFC6066）TLS拡張は、名前ベースの仮想ホストがHTTPS経由で機能するために必要です。

拡張機能は広く実装されており、現在のソフトウェアではまだ問題が発生していませんが、SNIに依存している場合、一部のクライアント（それをサポートしていないクライアント）がデフォルトのサイトにルーティングされる可能性があります。

6
Falcon Momot