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