同一 IP 地址和同一端口上的多个 SSL 域？

Question

同一 IP 地址和同一端口上的多个 SSL 域？

Joh*_*ohn 110 ssl virtualhost sni apache-2.2

这是一个关于在同一 IP 上托管多个 SSL 网站的规范问题。

我的印象是每个 SSL 证书都需要它自己唯一的 IP 地址/端口组合。但是我之前发布的一个问题的答案与这个说法不一致。

使用来自该问题的信息，我能够获得多个 SSL 证书以在相同的 IP 地址和端口 443 上工作。鉴于上述假设，我很困惑为什么这有效，并得到其他人的强化，即每个 SSL 域网站上的同一台服务器需要自己的 IP/端口。

我怀疑我做错了什么。可以这样使用多个 SSL 证书吗？

Answer 1

Mic*_*ton 97

是的，但有一些注意事项。

这是通过服务器名称指示（传输层安全性的扩展）实现的。

什么是服务器名称指示？

服务器名称指示（RFC 6066；过时的RFC 4366、RFC 3546）是传输层安全的扩展，它允许客户端告诉服务器它试图访问的主机的名称。

根据规范，SNI 与 TLS 1.0 及更高版本兼容，但实现可能会有所不同（见下文）。它不能与 SSL 一起使用，因此连接必须协商 TLS（请参阅RFC 4346 附录 E）才能使用 SNI。这通常会通过支持的软件自动发生。

为什么需要 SNI？

在正常的HTTP连接中，浏览器使用Host:标头将它试图访问的服务器的主机名通知服务器。这允许单个 IP 地址上的 Web 服务器为多个主机名提供内容，这通常称为基于名称的虚拟主机。

另一种方法是为每个要提供服务的 Web 主机名分配唯一的 IP 地址。这在网络的早期很常见，在广为人知的 IP 地址将耗尽和保护措施开始之前，SSL 虚拟主机仍然是这样做的（不使用 SNI）。

因为这种传输主机名的方法需要已经建立连接，所以它不适用于 SSL/TLS 连接。到建立安全连接时，Web 服务器必须已经知道它将为客户端提供哪个主机名，因为 Web 服务器本身正在设置安全连接。

SNI 通过让客户端传输主机名作为 TLS 协商的一部分来解决这个问题，以便服务器已经知道应该使用哪个虚拟主机来为连接提供服务。然后服务器可以将证书和配置用于正确的虚拟主机。

为什么不使用不同的 IP 地址？

Host:由于 IPv4 地址短缺，HTTP标头被定义为允许从一个 IP 地址为多个 Web 主机提供服务，早在 1990 年代中期就被认为是一个问题。在共享 Web 托管环境中，可以通过这种方式使用单个 IP 地址为数百个独特的、不相关的网站提供服务，从而节省地址空间。

共享托管环境随后发现 IP 地址空间的最大消费者是安全网站需要具有唯一 IP 地址的需求，因此需要将 SNI 作为通往 IPv6 的权宜之计。今天，如果没有明显的理由，有时很难获得少至 5 个 IP 地址 (/29)，这通常会导致部署延迟。

随着 IPv6 的出现，这种地址保护技术不再是必要的，因为分配给单个主机的 IPv6 地址可能比今天整个 Internet 所包含的还要多，但这些技术很可能在未来很长一段时间内仍会用于为遗留 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 或更高版本，带有配置标志
Qt 4.8 或更高

服务器支持

大多数当前版本的流行服务器软件都支持 SNI。设置说明适用于其中的大多数：

Apache 2.2.12 或更高版本
Apache 流量服务器3.2.0 或更高版本
切诺基
HAProxy 1.5 或更高版本
IIS 8.0 或更高
lighttpd 1.4.24 或更高版本
LiteSpeed 4.1 或更高
nginx 0.5.32 或更高版本

客户支持

当前大多数 Web 浏览器和命令行用户代理都支持 SNI。

桌面

Chrome 5 或更高版本
- Windows XP 上的 Chrome 6 或更高版本
火狐 2 或更高版本
Internet Explorer 7 或更高版本，在 Windows Vista/Server 2008 或更高版本上运行
- 无论 IE 版本如何，Windows XP 上的 Internet Explorer 都不支持 SNI
Konqueror 4.7 或更高版本
Opera 8 或更高版本（可能需要启用 TLS 1.1 才能运行）
Windows Vista/Server 2008 或更高版本上的 Safari 3.0，或 Mac OS X 10.5.6 或更高版本

移动的

3.0 Honeycomb 或更高版本的 Android 浏览器
iOS 4 或更高版本上的 iOS Safari
Windows Phone 7 或更高版本

命令行

cURL 7.18.1 或更高版本
wget 1.14 或更高版本（发行版可能已经向后移植了SNI 支持补丁）

没有支持

黑莓浏览器
Windows XP 上的 Internet Explorer（任何版本）

（注意：这个答案的一些信息是从维基百科获得的。）

Answer 2

vor*_*aq7 68

有关 Apache 和 SNI 的最新信息，包括其他特定于 HTTP 的 RFC，请参阅Apache Wiki

FYsI：TLS 升级的魔力为您带来了“一个 IP 上的多个（不同）SSL 证书”。它适用于较新的 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'

Run Code Online (Sandbox Code Playgroud)

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.

Run Code Online (Sandbox Code Playgroud)

这非常有用 - 谢谢！有关如何为 TLS 而不是 SSL 配置 Apache 的任何信息？ (2认同)
我认为 Apache 2.2 只需要在其密码列表中启用 TLS 位。我承认，在这两个站点之前，我从来没有看到过整个“从 SSL 升级到 TLS”的部分。我对 TLS 文档的理解是，协商这种升级是一种允许（但不寻常）的情况...... (2认同)

Answer 3

Ken*_*ert 37

问题：

当 Web 客户端和 Web 服务器通过 HTTPS 相互通信时，需要发生的第一件事就是安全握手。

这是这种握手的简化示例：

如果这是 HTTP 而不是 HTTPS，客户端发送的第一件事应该是这样的：

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

Run Code Online (Sandbox Code Playgroud)

这使得单个 IP 地址上的多个虚拟主机成为可能，因为服务器确切地知道客户端想要访问的域，即 example.com。

HTTPS 是不同的。就像我之前说的，握手先于一切。如果您查看上面说明的握手的第三步（证书），服务器需要向客户端提供证书作为握手的一部分，但不知道客户端尝试访问哪个域名。服务器唯一的选择是每次发送相同的证书，即默认证书。

您仍然可以在 Web 服务器上设置虚拟主机，但服务器将始终向每个客户端发送相同的证书。如果您尝试在服务器上同时托管 example.com 和 example.org 网站，则服务器将始终在客户端请求 HTTPS 连接时发送 example.com 的证书。因此，当客户端通过已建立的 HTTPS 连接请求 example.org 时，会发生这种情况：

在此处输入图片说明

这个问题有效地将您可以通过 HTTPS 服务的域数量限制为每个 IP 地址一个。

解决方案：

解决这个问题最简单的方法是让客户端在握手过程中告诉服务器它想访问哪个域。这样服务器就可以提供正确的证书。

这正是SNI或 Server Name Indication 所做的。

使用 SNI，客户端发送它想要访问的服务器名称作为第一条消息的一部分，即上面握手图中的“客户端问候”步骤。

一些较旧的 Web 浏览器不支持 SNI。例如，在 Windows XP 上，没有单一版本的 Internet Explorer支持 SNI。在使用 SNI 虚拟主机的服务器上通过 HTTPS 访问资源时，您将看到一个通用证书，这可能会导致浏览器显示警告或错误。

在此处输入图片说明

我在这里简化了一些事情，只是为了解释问题背后的原理和解决方案。如果您想要更技术性的解释，维基百科页面或RFC 6066可能是一个很好的起点。您还可以在维基百科上找到支持 SNI 的服务器和浏览器的最新列表

Answer 4

Cra*_*aig 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

Run Code Online (Sandbox Code Playgroud)

Answer 5

Fal*_*mot 6

服务器名称指示 (RFC6066) TLS 扩展是基于名称的虚拟主机通过 HTTPS 工作所必需的。

该扩展已广泛实施，我还没有遇到当前软件的任何问题，但是如果您依赖 SNI，则有可能将某些客户端（不支持它的客户端）路由到您的默认站点。

归档时间：	15 年，7 月前
查看次数：	75953 次
最近记录：	9 年，7 月前