我有一个 IIS 网站，它托管 3 个不同的网站，它们都使用相同的 UCC SSL 证书。（我网站的代码会检查主机标头本身以确定要显示的网站变体）。
我已经为我在 XP 上的 Internet Explorer 用户修复了我最致命的错误，即禁用 IIS 中的“需要主题名称指示”字段。由于Windows XP 不支持SNI ，如果在 XP 用户切换到 HTTPS 时启用它，他们基本上会在没有任何警告的情况下被踢出站点（不要告诉我的老板）。
所以我完全理解，当用户通过 HTTPS 访问 3 个站点中的任何一个时，这些站点都共享相同的 IP，他会被发送到同一个 IIS 站点并提供 UCC 证书。甚至 XP 也支持 UCC/SAN 证书，因此客户端接受证书并按预期显示站点。
现在....忘记所有这些并考虑第二个非假设情况。
- 假设我有两个站点：
cats.com和dogs.com - 它们是不同的站点，并且部署在 IIS 8 中的两个不同的网站中。
- 它们都在同一个 UCC SSL 证书上*
- SNI 已禁用
- 它们都绑定到同一个IP地址
现在考虑 XP 用户访问https://cats.com
以下是我对事情的理解：
- DNS 将我的 IP 还给浏览器 - 可以说
1.2.3.4 - 协商了一个 HTTPs 连接，但是因为 XP 对 SNI 一无所知，所以它没有发送 SSL 主机标头（或其他任何名称），而只是通过 IP 访问安全站点。
- 因此 IIS 将寻找与 https 网站绑定相关联的 IP，它实际上会找到两个。
- 假设 IIS 决定只为您提供第一个服务 - 所以它会为您提供
cats.com您所期望的。所以没关系。 - 但是让我们说你去
https://dogs.com- 你不应该实际为该站点提供服务，cats.com因为 XP 上的 SSL 不知道 SSL 连接的 SNI 并且无论如何它在 IIS 中被禁用？
好吧，你没有。你得到dogs.com。我已经尝试过了，cats.com并且dogs.com两者都可以在 Windows XP Internet Explorer 8 客户端上运行。
我只是不明白为什么会这样。只有在我的第一个场景中，当它们都共享一个 IIS 应用程序时，我才会预料到这种行为。
我最好的猜测是 IIS 8 无论如何都会接收主机标头，并且足够聪明，可以将其路由到正确的网站并找到 UCC 证书名称。是这样吗？
有人可以进一步解释吗？
* 只是为了故意惹恼有技术头脑的猫狗主人 ;-)
IIS 使用 HTTP Host: 标头来确定要服务的网站，就像处理任何其他请求一样。