同じIPアドレスと同じポートに複数のSSLドメインがありますか?


109

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

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

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

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


このQの本文には、複数の証明書があり、その答えは正しいと言われています。しかし、タイトルには複数のドメインがあり、1つの証明書(SNIなし)で複数のドメインを持つことができます。serverfault.com / questions / 126072 /… およびserverfault.com/questions/279722/…もsecurity.SXを参照してください。
dave_thompson_085

回答:


68

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


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

RFC 2817(HTTP / 1.1内のTLSへのアップグレード)には詳細がありますが、基本的には多くの人々(大多数ではないにしても)に有効です。ただし
、opensslのs_clientコマンド(または「古い」ブラウザー)を使用して、古いファンキーな動作を再現できます。

編集して追加:curlopensslよりもここで何が起こっているかをよりよく示すことができます:


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.

2
それは非常に便利です-ありがとう!SSLではなくTLS用にApacheを構成する方法に関する情報はありますか?
ジョシュ

2
Apache 2.2では、暗号リストでTLSビットを有効にするだけでよいと思います。ただし、これら2つのサイトまでは、「SSLからTLSへのアップグレード」ビット全体が動作していることは一度もありません。TLSドキュメントの私の理解は、この種のアップグレードをネゴシエートすることは許容できる(しかし異常な)状況であるということです
...-voretaq7

どちらかを見たのはこれが初めてで、まだ顎を床から引き離そうとしています
ジョシュ

1
答えは長さが3倍になりました-どうやらcurlはSSLv3とTLSv1の両方のネゴシエーションを実行できるので、失敗と成功を示すことができます。しかし、魔法の部分を示すのに便利なプロトコルデバッガがあればいいのにと思います。(また、johnlai2004のサーバーがSSLv2接続を正しく拒否することをテストし、喜んで報告します:-)
voretaq7

それは非常に役に立ち、johnlai2004があなたの答えを受け入れることを願っています。どうもありがとう!
ジョシュ

97

はい。ただし、いくつかの注意事項があります。

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

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

サーバー名表示RFC 6066、廃止されたRFC 4366RFC 3546)は、クライアントが到達しようとしているホストの名前をサーバーに伝えることができるトランスポート層セキュリティの拡張機能です。

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

SNIが必要な理由

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

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

このホスト名の送信方法では、接続が既に確立されている必要があるため、SSL / TLS接続では機能しません。セキュア接続がセットアップされるまでに、Webサーバー自体がセキュア接続をセットアップしているため、Webサーバーはクライアントに提供するホスト名をすでに知っている必要があります。

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

異なるIPアドレスを使用しないのはなぜですか?

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

共有ホスティング環境では、IPアドレス空間の最大の消費者は、安全なWebサイトに一意のIPアドレスを持たせる必要があることがわかったため、IPv6への道のりの手段としてSNIが必要になりました。今日では、正当な理由なしにわずか5個のIPアドレス(/ 29)を取得することが困難な場合があり、多くの場合、展開の遅延が発生します。

IPv6の出現により、単一のホストに現在のインターネット全体に含まれるよりも多くのIPv6アドレスを割り当てることができるため、このようなアドレス節約技術は不要になりましたが、おそらく従来のIPv4を処理するためにこの技術は今後も使用されるでしょう接続。

注意事項

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

特に注意すべきは、Windows XP上のInternet Explorerのどのバージョンも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以降、configureフラグ付き
  • Qt 4.8以降

サーバーサポート

一般的なサーバーソフトウェアの最新バージョンはSNIをサポートしています。これらのほとんどについて、セットアップ手順が利用可能です。

クライアントサポート

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

デスクトップ

  • Chrome 5以降
    • Windows XP上のChrome 6以降
  • Firefox 2以降
  • Windows Vista / Server 2008以降で実行されているInternet Explorer 7以降
    • IEのバージョンに関係なく、Windows XP上のInternet Explorerは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サポート用のパッチをバックポートしている場合があります)

サポートなし

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

(注:この回答の一部の情報は、ウィキペディアから取得されました。)


1
はるかに良い:-)うまくいけば、最終的に現在受け入れられているスコアよりも高いスコアが得られることを願っています。
ブルーノ

1
@Bruno投票する数百人を見つけても文句を言うことはありません。:)
マイケルハンプトン

最新のBlackBerry Browser(10?)はWebKitの最新バージョンを使用しているため、現在SNIをサポートしている可能性が非常に高いです。
dave1010

37

問題:

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

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

TLSハンドシェイク

これが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を要求すると、次のようになります。

ここに画像の説明を入力してください

この問題により、HTTPSでサーバーできるドメインの数がIPアドレスごとに1つに制限されます。

ソリューション:

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

これは、まさにSNIまたはサーバー名表示が行うことです。

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

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

ここに画像の説明を入力してください

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


16

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 

6

サーバー名の表示(RFC6066)TLS拡張は、名前ベースのvhostがHTTPS上で機能するために必要です。

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


Falconの回答に加えて、IISでは、複数のIISサイトを同じIPで動作させるためにいくつかの特別な変更が必要です。サーバーの構成ファイルを手動で編集するか、CLIツールを使用してバインドを変更する必要がありますが、GUIツールではできません。IISでは、SSL証明書をホストヘッダーに割り当てると呼ばれます。Apacheにはしばらくの間問題がありませんでした。
ブレントパブスト

ああ大丈夫、それはいくつかをクリアします。クライアント(ブラウザ)がこれをサポートしているかどうかはどうすればわかりますか?たとえば、MSIE6を確認したい場合、仮想XPマシンなどをインストールせずにどのようにテストできますか?
リュック


1
@Falcon SNIは、XP上のIEでは機能しません。デスクトップインターネットユーザーのほぼ4分の1を占めています。潜在的な訪問者の4分の1が働いていないときは、「広く実装されている」とは言いません。
クリスS

1
@MichaelHampton IEは、SSLにネイティブのWindows暗号化スタックを使用します。XPはSNIをサポートしていないため、XPを実行しているIEのどのバージョンもサポートしていません。IEはVista以降のOSでのみSNIをサポートします。
クリスS
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.