.htaccess 重定向仅在浏览器警告后执行 [英] .htaccess redirect only executes after browser warning

问题描述

我有一个强制使用 HTTPS 和 www 的重写规则.SSL 证书适用于网站的 www 版本.整个网站需要是 HTTPS.

I have a rewrite rule which forces HTTPS and www. The SSL certificate is for the www version of the site. The entire site needs to be HTTPS.

问题是如果请求是https://example.com/ 浏览器会在之前显示警告页面重定向可以执行.(Firefox 中为此连接不受信任"，Chrome 中为这可能不是您要查找的站点！")

The problem is that if the request is https://example.com/ the browser displays a warning page before the redirect can execute. ('This Connection is Untrusted' in Firefox and 'This is probably not the site that you are looking for!' in Chrome)

如果用户在 Firefox 中添加异常或忽略 Chrome 中的错误，则重写规则会执行，并且他们将重定向到具有 100% 安全页面的 www 版本网站.

If the user adds an exception in Firefox or ignores the error in Chrome, the rewrite rule executes and they are redirects to the www version of the site with a 100% secure page.

RewriteEngine on

RewriteCond %{HTTP_HOST} ^example.com$ [OR]
RewriteCond %{HTTPS} !on
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

RewriteCond %{HTTP_HOST} ^www.example.com$
RewriteCond %{HTTPS} !on
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

我一直在网站和 http://martinmelin.se 上测试规则/rewrite-rule-tester/

如何在浏览器警告之前执行重定向?

How can I get the redirect to execute before the browser warning?

推荐答案

从 https://example.com 到 https://www.example.com 的重定向> 只能在客户端向 https://example.com 发出初始成功请求后发生.

The redirection from https://example.com to https://www.example.com can only happen after the client has made an initial successful request to https://example.com.

这是因为 HTTPS 是基于 TLS/SSL 的 HTTP(请参阅RFC 2818)，它首先在发送任何 HTTP 流量之前建立 SSL/TLS 连接.mod_rewrite 将始终在 SSL/TLS 连接建立后应用.不这样做实际上是一个安全问题，因为攻击者可以在验证证书之前重写和重定向客户端.即使 TLS 升级在 HTTP(RFC 2817，它实际上从未使用/支持并且不是 https)内，您仍然希望重定向来自受信任的实体.

This is because HTTPS is HTTP over TLS/SSL (see RFC 2818), which first establishes the SSL/TLS connection before any HTTP traffic is sent. mod_rewrite will always apply after the SSL/TLS connection is established. Not doing so would actually be a security issue, since an attacker could rewrite and redirect the client before the certificate has been verified. Even if the TLS upgrade was within HTTP (RFC 2817, which is virtually never used/supported and is not https), you would still want the redirection to come from a trusted entity.

要使此初始连接正常工作，https://example.com 上的服务器必须具有对 example.com 有效的证书，否则此连接将无效甚至不会发生(并且服务器不会发送重定向响应).

For this initial connection to work, the server at https://example.com must have a certificate valid for example.com, otherwise, this connection won't even happen (and the server won't send a redirection response).

为了实现您的目标，您需要对 https://example.com 的请求以提供对 example.com 有效的证书以及对 https 的请求://www.example.com 提供对 www.example.com 有效的证书.

To achieve your goal, you need requests for https://example.com to present a certificate valid for example.com and requests for https://www.example.com to present a certificate valid for www.example.com.

有两种解决方案:

• 为每个主机使用两个不同的证书，通过使用不同的 IP 地址或使用服务器名称指示.这里的缺点是并非所有客户端都支持 SNI，即使它变得越来越普遍.
• 使用对 example.com 和 www.example.com 都有效的单个证书.这可以通过获取具有多个主题备用名称 (SAN) DNS 条目的证书来实现(它不适用于 *.example.com，因为点不是通配符模式的一部分).

• Using two distinct certificates for each hosts, either by using distinct IP addresses or by using Server Name Indication. The downside here is that not all clients support SNI, even if it's getting more common.
• Using a single certificate that is valid for both example.com and www.example.com. This can be achieved by getting a certificate with multiple Subject Alternative Name (SAN) DNS entries (it won't work with just *.example.com since the dot isn't part of the wildcard pattern).

后者当然是最简单的解决方案.当您申请一个或另一个时，CA 颁发具有 example.com 和 www.example.com SAN 条目的证书是很常见的，有时没有额外的费用.

The latter is certainly the easiest solution. It's quite common for CAs to issue certificates that have SAN entries for both example.com and www.example.com when you apply for one or the other, sometimes without an extra fee.

这篇关于.htaccess 重定向仅在浏览器警告后执行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！