是和否。

可能有多个证书都具有相同的域名。您可以拥有 Comodo example.org 证书和 Entrust example.org 证书，它们都是有效且官方的，没问题。我相信一些负载均衡器会轮换每个连接使用哪个负载均衡器，但只能以循环方式使用。

否是您询问是否可以根据 URI（/ 与 /criticalpath）选择要使用的证书。问题是，只有在使用两个证书之一确定 SSL 连接后，该 URI 才可用。因此，您无法真正根据选择证书后才能拥有的信息来选择要使用的证书。

现在，我不会说 100% 这是不可能的。例如，使用 Apache，您可以在每个目录的基础上设置SSLCipherSuite配置，因此如果有某种方法可以强制重新协商涉及新证书，我不会感到惊讶。但我宁愿怀疑它实际上没有实现，即使它在理论上是可能的。（Apache SSLCertificate* 是每个服务器或每个虚拟主机，而不是每个目录）。

附录：重新谈判的思考

免责声明：我没有做过任何这些，这是对 RFC 和其他文档的外行解释。这里有几十个人比我更有资格发表评论。

我将看一下 TLS 1.2，因为它在RFC 5246 中得到了简洁的描述。

第 7.4.1.1 节，“服务器可以随时发送 HelloRequest 消息。” 这应该会触发客户端重新协商连接。（客户端可能会忽略该请求，如果客户端忽略该请求太久，服务器可能会断开连接。）

重新谈判看起来很像初始谈判，尽管它可能会传递来自先前谈判的一些信息以尝试使路径顺利进行（例如，这是我们上次商定的密码）。所以客户端发送一个ClientHello，然后服务器发送一个ServerHello，然后服务器发送一个 服务器证书（7.4.2）。

所以我对 RFC 的解读是，是的，服务器可以强制重新协商连接，包括选择不同的服务器证书。

老实说，我不知道你会发现现有的软件可以做你想做的事。我建议您开始使用 Perl Crypto::OpenSSL 或 Python 的 ssl 库，看看您是否可以测试它。

不。没有 Web 服务器可以支持此功能；不是现在，也不是。原因如下：

HTTPS 按以下顺序执行以下步骤：

1. 客户端连接到服务器
2. SSL/TLS 协商（包括交换证书、证书验证和加密设置）
3. 客户端发送请求（包括服务器主机名、路径、cookie 等）
4. 服务器发回响应（包括响应头、内容等）

请注意，上面的第 2 步发生在第 3 步之前。也就是说，在浏览器告诉服务器它要查找的 URL 之前，整个加密工作已经完全完成。这意味着当服务器选择要使用的 SSL 证书时，它还不知道 URL 路径是什么。由于该信息在该阶段不可用，因此无法将其作为决定使用哪个证书的因素。

另请注意，主机名在步骤 3 中发送到服务器，这就是每个证书通常安装在唯一 IP 地址上的原因；服务器使用 IP 地址来确定要出示的证书。较新版本的 SSL/TLS 添加了名为服务器名称标识的扩展，以允许客户端在 TLS 协商期间指定主机名，但这仅适用于主机名。

没有规定允许基于 URL 路径选择证书，也永远不会，因为这意味着 URL 路径需要作为证书选择的一部分发送到未加密的服务器。对于安全页面，发送未加密的 URL 是不可接受的。

我认为使用 SSL 卸载、深度数据包检查和 TLS 重新协商可能是可能的。但是，如果您在 google 上搜索 TLS 重新协商，前 20 名的点击量将与重新协商漏洞有关——因此，如果您这样做，您最终可能会使您的网站变得不那么安全，而不是更多。

另一方面，如果您的方案是这样的：

https://example.org/

https://criticalpath.example.org/

这将是微不足道的。您只需将这两个域路由到不同的内部 IP，并将 IP 绑定到不同的证书。