在工作中，我被要求增加对将多个密钥映射到单个（甚至多个）IP到本质上被动的HTTP嗅探器的支持。 它支持用户上传的密钥进行SSL解密。 目前，它支持一个IP到一个密钥的映射，或一个IP到多个密钥的映射。 问题出在通知方面。 目前我们发送SNMP陷阱和/或电子邮件，如果密钥不再起作用。 使用多对多的映射，我将无法知道失败是否是由于一个映射键已经改变的模数（因此键已经改变），或者它只是一个额外的键被添加，或者系统pipe理员对解密不感兴趣。 主要的问题在于这里，因为它将被实现的方式，除非完全重写被允许，还将打破一对一IP /密钥映射的当前通知。
我认为这是错误的，这是我的观点。 有人可以帮我支持与老板的这个论点吗？ 或者，如果我错了，请告诉我我的推理错误在哪里。
这个function是必需的，因为显然有一个用例，一个webapp中的多个节点使用不同的密钥，即使它们都映射到一个VIP。 请求这个function的人坚持说他们已经在客户端环境中看到了这个function。 我想确认这是一个错误的观察，但我没有tcpdumps这样做。 我认为，对于一个单独的IP，SSL协商将始终发送相同的证书，因此将使用相同的密钥，因为没有HTTPS已经完成，它只知道到IP的连接，不知道什么主机：在这个阶段，头文件存在于webapp / server上，以确定应用程序将会响应什么。 因此，在我看来，不能有这样的用例。 是否有一个负载均衡器可以让您将两个密钥放到一个VIP中？
而且，即使可以做到这一点，基于SSL协商的方式，也无法控制terminal用户甚至收到正确的证书。 这基本上是一个破碎的设置。 我想不出一个有效的用例，它不会导致客户端的随机SSL不匹配错误。
所以，我疯了，觉得这不应该被支持？ 如果是这样，我很想知道何时将多个密钥映射到单个IP是一个有效的用例。 如果没有，请为此提供进一步的build设性论据 – 因为我上述论点没有成功。 到目前为止的答复是“系统pipe理员不胜任的问题不是我们的问题，我们应该支持”
编辑：我打破了标题
服务器名称指示是对SSL / TLS的补充，客户端可以在初始握手期间指示要寻找哪个主机名，然后传送HTTP请求标头，这通常是告诉服务器正在使用哪个主机。 然后，服务器可以根据这些信息select要显示的证书。
由于缺乏Windows XP的支持，它的使用并不是非常广泛，但是大多数其他操作系统/浏览器组合在这一点上都支持它，大多数主要的Web服务器（不是IIS）都希望它在一旦XP部署终于结束了。
所以，不幸的是，为了您的需要，确实有一个IP会向HTTPS客户端提供多个不同的证书。