为Apache上的特定虚拟主机禁用SNI

正如其他人所说，只是把第一个网站作为第一个虚拟主机，它将工作，无论SNI是否启用：

 <VirtualHost *:443> ServerName www.site1.com DocumentRoot /site1/ SSLCertificateKeyFile /ssl/server1.key SSLCertificateFile /ssl/server1.crt </VirtualHost> <VirtualHost *:443> ServerName www.site2.com DocumentRoot /site2/ SSLCertificateKeyFile /ssl/server2.key SSLCertificateFile /ssl/server2.crt </VirtualHost> 

但是，对于站点2的非SNI浏览器将被用作站点1的证书，因此将出现错误（并且用户可能想知道为什么他们为不同的站点获得证书，但是如果仍然在非SNI浏览器上，他们可能不是技术精明）。

但是，即使存在明显的SNI问题，也可以为所有网站的所有用户提供访问权限，前提是您拥有覆盖所有网站主题备用名称字段的单一证书。

您可以使用相同的密钥和证书拥有两台虚拟主机：

 <VirtualHost *:443> ServerName www.site1.com DocumentRoot /site1/ SSLCertificateKeyFile /ssl/server.key SSLCertificateFile /ssl/server.crt </VirtualHost> <VirtualHost *:443> ServerName www.site2.com DocumentRoot /site2/ SSLCertificateKeyFile /ssl/server.key SSLCertificateFile /ssl/server.crt </VirtualHost> 

所以你有两个网站（或三个，如果你想要更多的）相同的密钥和证书。

所以www.site1.com总是作为，即使没有SNI的支持，它是默认主机。

对于www.site2.com它变得更有趣：

• 对于支持SNI的浏览器，他们提供服务器名称，并直接进入site2虚拟主机configuration，并工作。
• 对于不支持SNI的浏览器，它们默认为site1configuration，它返回它的证书，但是由于证书适用于这两个站点，所以实际上可以。 SSL协商完成后，第一个Web请求会进入，但是由于这次服务器被赋予服务器名称，所以它可以正确地服务来自/ site2 /目录的文档。

因此，这是有效的，因为https连接涉及两个不同且不相关的步骤：1）使用该SSL连接进行SSL协商和2）请求文档，这两个步骤不必来自同一个虚拟主机（尽pipe大多数人认为它）。

这个选项的主要缺点是，根据网站的相关程度，在同一个证书上有两个不同的URL可能看起来并不专业。 然而，大概如果他们共享一个主机，他们有些相关的业务（除非服务器是托pipe公司所有），所以这可能不是一个问题。

我发现这是一个方便的小解决方法，特别是对于我可能希望在一个IP地址上托pipe多个站点的开发服务器，我在这个主题替代名称字段中使用自签名的多个URL。

您不要在服务器端“禁用”SNI，甚至无法控制客户端是否发送扩展名。 你所能做的就是定义你的服务器如何响应SNI信息的存在（或不存在）。

通常，当服务器接收到缺lessSNI信息的请求时，它将select可用于向客户端呈现的证书之一。 对于Apache，它将是正在侦听的地址/端口对的第一个虚拟主机。

关于您是否希望在没有SNI的情况下安全访问的网站是否有单独的“非SNI”地址，我认为这不重要。 你可以保存一个有价值的IPv4地址，把它们全部放在同一个IP地址上。 任何从非SNI浏览器访问仅SNI网站的人都将获得相同的证书警告，无论其是否与非SNI网站的地址相同。 唯一的考虑是您是否希望支持非SNI客户端的站点的证书在访问仅SNI站点时呈现给非SNI客户端。

我现在打了很多次“SNI”，开始失去了所有的意义。