Apache 2.4 上的 Catch-All HTTPS Vhost

Question 1

问题解决了，但是存在一些误解。HTTPS 确实需要匹配的证书，但由此导致的问题是，如果主机名不匹配证书，则连接将不受信任通用名称或列于主题备用名称：

RewriteRule即使采用其他答案中给出的解决方案，仍然存在同样的不匹配情况。
如果“catch-all”主机名都是的子域，example.com并且您拥有的通配符证书*.example.com，则它将匹配。
另一方面，大多数人在尝试访问时something.example.com，都会在浏览器地址栏中输入不带http://或https://前缀的地址，而浏览器默认使用 HTTP。因此，即使证书不匹配，在 HTTPS 上使用“catch-all”重定向通常也不会导致任何实际问题：只有少数人会看到该SSL_ERROR_BAD_CERT_DOMAIN错误。

这虚拟主机匹配无论有没有 TLS，工作方式都相同。

如果你没有信噪比：

配置文件中给定对的第一个基于名称的虚拟主机 IP:port非常重要，因为它用于接收该地址和端口上的所有请求，而该对中没有其他虚拟主机 IP:port具有匹配的ServerName或者ServerAlias. 如果服务器不支持，它也用于所有 SSL 连接服务器名称指示。

没有 SNI第一个证书VirtualHost用于握手：

实际上，Apache 将允许您配置基于名称的 SSL 虚拟主机，但它将始终使用第一个列出的虚拟主机（在选定的 IP 地址和端口上）的配置来设置加密层。

您最初尝试的主要问题是有ServerAlias *和没有ServerName。对于“万能”主机，它应该与无论如何其他ServerNames 与其他VirtualHosts 匹配。如果没有其他匹配项，Apache 将返回到默认VirtualHost部分；以第一个部分为准（当基于名称的查找失败时，该部分与基于 IP 的查找匹配）。

最佳匹配集的基于名称的虚拟主机<virtualhost>将按照其在配置中出现的顺序进行处理。第一个匹配ServerName或ServerAlias被使用，通配符的优先级没有不同（与一样ServerName）ServerAlias。

一定有一些ServerName因为：

该ServerName指令可以出现在服务器定义中的任何位置。但是，每次出现都会覆盖前一次出现（在该服务器内）。

如果没有ServerName指定，服务器将尝试通过首先向操作系统询问系统主机名来推断客户端可见的主机名，如果失败，则对系统上存在的 IP 地址执行反向查找。

这将导致如下配置：

<VirtualHost *:443>
    # Default catch-all (everything that won't match the following VirtualHosts)
    ServerName catch-all.example.com
    ServerAlias www.example.com
    SSLEngine on
    SSLCertificateFile "C:/prod/hosts.crt.pem"
    SSLCertificateKeyFile "C:/prod/hosts.key.pem"
    SSLCertificateChainFile "C:/prod/intermediate.crt.pem"  
    Redirect permanent / https://example.com
</VirtualHost>

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile "C:/prod/hosts.crt.pem"
    SSLCertificateKeyFile "C:/prod/hosts.key.pem"
    SSLCertificateChainFile "C:/prod/intermediate.crt.pem"  
    Include conf/sites/example.com.conf
</VirtualHost>

<VirtualHost *:443>
    ServerName dev.example.com
    SSLEngine on
    SSLCertificateFile "C:/prod/hosts.crt.pem"
    SSLCertificateKeyFile "C:/prod/hosts.key.pem"
    SSLCertificateChainFile "C:/prod/intermediate.crt.pem"  
    Include conf/sites/dev.example.com.conf
</VirtualHost>

请注意我还做了以下改变：

dev.example.com使用与没有 SNI 时相同的证书。
使用<VirtualHost *:443>而_default_:443不是_default_有一个特殊用途：

任何包含魔法_default_通配符的虚拟主机都会被赋予与主服务器相同的 ServerName。

（这也意味着可以_default_:443在您的“catch-all”中使用，而不能在其他中使用。您可以尝试！）
域名已替换为预留示例域名。
我更愿意将其www.example.com作为“catch-all”的一部分（而不是作为别名），以便拥有只有一个规范地址您的网站。因此我已将其移至那里。

如果你有信噪比，处理模仿相同的行为，但在细节上略有不同：

在 SSL 握手之前，Apache 就会找到建立连接的 IP 地址和 TCP 端口的最佳匹配（基于 IP 的虚拟托管）

如果存在NameVirtualHost与此最佳匹配项具有相同文字参数的指令VirtualHost，Apache 将改为考虑VirtualHost与匹配的 VirtualHost 具有相同参数的所有条目。否则，SNI 处理将无法执行任何选择。

如果客户端在 TLS 握手请求中发送了主机名，Apache 会将此 TLS 主机名与前面步骤中确定的候选集的ServerName/进行比较。ServerAliasVirtualHost

无论根据上述原则选择哪个 VirtualHost，都将使用其 SSL 配置来继续握手。值得注意的是，证书的内容不会用于任何比较。

通过 SNI 您可以获得附加证书dev.example.com。

如果满足 SNI 的所有先决条件，它就会自动运行并error.log显示[warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)。

Answer

问题解决了，但是存在一些误解。HTTPS 确实需要匹配的证书，但由此导致的问题是，如果主机名不匹配证书，则连接将不受信任通用名称或列于主题备用名称：

RewriteRule即使采用其他答案中给出的解决方案，仍然存在同样的不匹配情况。
如果“catch-all”主机名都是的子域，example.com并且您拥有的通配符证书*.example.com，则它将匹配。
另一方面，大多数人在尝试访问时something.example.com，都会在浏览器地址栏中输入不带http://或https://前缀的地址，而浏览器默认使用 HTTP。因此，即使证书不匹配，在 HTTPS 上使用“catch-all”重定向通常也不会导致任何实际问题：只有少数人会看到该SSL_ERROR_BAD_CERT_DOMAIN错误。