在 centos 7 多站点服务器上通过 .htaccess 或 VirtualHost .conf 重定向流量失败并显示 https

在 centos 7 多站点服务器上通过 .htaccess 或 VirtualHost .conf 重定向流量失败并显示 https

我有一台 Centos 7 服务器,配置为多站点虚拟主机。我尝试使用此服务器执行的操作之一是将旧子域的流量重定向到我们主网站上的子目录。主站点不在同一台服务器上。

我已经使用纯 VirtualHost 配置和 .htaccess 尝试了大量配置。我总是可以让它与 HTTP 一起工作,但永远不能与 HTTPS 一起工作,因为这个 VirtualHost 没有 SSL 证书,而且我不能为其购买一个仅用于重定向流量的证书。

所以,http://bort.example.com重定向到https://www.example.com/bort很好,但是https://bort.example.com总是给出有关无效证书的安全错误。

我目前的理论是,如果重定向服务器上没有证书,apache 甚至拒绝处理 .htaccess 文件,因此我完全摆脱了它,并尝试将 VirtualHost 配置提炼为最简单的方法。这就是我现在所拥有的。

<VirtualHost *:80>
    ServerName bort.example.com
    Redirect / https://www.example.com/bort
</VirtualHost>

<VirtualHost *:443>
    ServerName bort.example.com
    Redirect / https://www.example.com/bort
</VirtualHost>

这对于 HTTP 流量仍然可以正常工作。我缺少什么来让它工作https://bort.example.com

编辑:看起来该服务器上的另一个网站 lisa.example.com 确实有 SSL 证书,这可能是一个促成因素。尝试到达时收到的实际错误https://bort.example.com这是:

bort.example.com uses an invalid security certificate.

The certificate is only valid for the following names:
lisa.example.com
Error code: SSL_ERROR_BAD_CERT_DOMAIN

答案1

在 HTTPS 中,连接开始时的操作顺序......不太理想。这是因为 HTTP 最初是与 SSL/TLS 分开设计的,并且这两种技术并不完美地结合在一起。

当服务器接受任何传入的 HTTPS 连接时,第一步是 SSL/TLS 协商。这发生在通过连接传递任何其他数据之前 - 特别是,在客户端有机会发送指定客户端请求的服务器名称的 HTTP(s) 标头之前。

因此,如果服务器具有针对不同站点的多个证书,则它可能需要盲目地选择一个并希望它是客户端请求的站点的证书。如果提供了错误的证书,客户端将拒绝相信服务器在该连接上发送的任何内容,因此无法重定向客户端。 “等等,我想要,bort现在你的证书证明你的名字是lisa?这是一个错误或更糟糕的事情,我不想和你说话。”客户端甚至不会给服务器提供重定向信息的机会。

随着基于名称的虚拟主机变得普遍,开发了两种技术来解决此问题:服务器名称指示 (SNI) 和服务器备用名称 (SAN)。

服务器名称指示是一种 SSL/TLS 扩展,允许客户端在 SSL/TLS 协商的早期阶段告知服务器的名称,而不仅仅是在 HTTP(s) 请求标头中。如果服务器支持 SNI,则它可以选择正确的证书来呈现给客户端。当然,每个 VirtualHost 必须有自己的证书:对于 Apache,它意味着每个虚拟主机的SSLCertificateFile参数SSLCertificateKeyFile,指向与ServerName该虚拟主机的证书相匹配的证书。如果您还没有 的证书bort,则需要获取一个。

另一种选择是拥有适用于多个虚拟主机的证书。这就是服务器备用名称技术的用武之地。它是一种证书扩展,允许证书列出其适用的多个主机名。您可以为您的服务器获取一个新证书,该证书使用 SAN 列出lisa.example.combort.example.com作为证书的有效 DNS 名称。当然,获得新证书可能会很麻烦。

不幸的是,由于 SNI 和 SAN 都是后来添加到 SSL/TLS 标准的,所以最古老的浏览器不一定支持它们。但基本上这十年发布的任何浏览器都应该很好地支持它们。

相关内容