我们目前正在尝试设置具有多个证书的 HTTPS。我们取得了一些有限的成功,但我们得到了一些我无法理解的结果......
基本上,我们的 NLB 上有两台服务器(10.0.51.51 和 10.0.51.52)和分配给 NLB 的两个 IP(10.0.51.2 和 10.0.51.4),我们让 IIS 使用不同的通配符证书(To避免提供公共(public) IP,比如 A:443 路由到 10.0.51.2:443 和 B:443 路由到 10.0.51.4:443)。我们还有一个 Cisco 路由器,它使用端口地址转换将端口 443 从两个外部 IP 路由到这些内部 NLB IP。
奇怪的是,如果我们请求 A:443 或 B:443,这会起作用,但如果你在内部访问 10.0.51.51:443、10.0.51.52:443、10.0.51.2:443 或 10.0.51.4:443,你总是会得到相同的 SSL 证书。该证书过去分配给 *:443,但我们已确保在 IIS 中不再定义 * 绑定(bind)。
当我在删除所有不相关的东西后运行“netsh http show sslcert”时:
IP:port : 0.0.0.0:443
Certificate Hash : <Removed: Cert 1>
IP:port : 10.0.51.2:446
Certificate Hash : <Removed: Cert 3 - Another site>
IP:port : 10.0.51.3:446
Certificate Hash : <Removed: Cert 3 - Another site>
IP:port : 10.0.51.4:443
Certificate Hash : <Removed: Cert 2>
这告诉我 * 绑定(bind)仍然在那里,这有点奇怪,但我不明白为什么这会阻止另一个工作(或者更奇怪的是为什么通过路由器的请求会工作)。
这让我想知道它是否实际上将请求视为机器的 IP 而不是 NLB IP,但不幸的是,我们的开发环境只是一个服务器,它减少了我可以对此进行的试验/错误的数量(因为我可以测试on 是一个实时环境)而没有说服管理层为测试环境购买更多服务器 - 这是我正在尝试的事情。
有谁有想法吗:
最佳答案
我最终追踪了这个问题。将此作为对落入同一陷阱的其他任何人的提示...
该问题是由我们在 IIS 服务器上使用共享配置模型引起的。设置 HTTPS 绑定(bind)时,这似乎只是将它实际绑定(bind)在您管理它的盒子上(让另一个完全未绑定(bind))。由于我们的 * 绑定(bind)仍然存在,它在服务器上捕获它,我们没有通过 UI 进行操作,只是让我们获取共享配置。
单亲和 NLB 的糟糕运气让我们在路由器成为原因之后让我们的内部请求发送到一台服务器而我们的外部请求发送到另一台服务器。
我们最终通过在两台服务器上运行“netsh http show sslcert > certs.txt”并比较输出来发现这一点。
展望 future ,我们的计划是不再使用 IIS UI 进行 SSL 配置,而是按照以下步骤操作:
我们的理解是,这将防止重复此错误。
关于networking - 软件 NLB 的 IIS7 群集上的 HTTPS 多个证书,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1777408/