htaccess HSTS 防止从 www.subdomain.domain.com 重定向到 subdomain.domain.com答案

【问题标题】：htaccess HSTS prevents redirection from www.subdomain.domain.com to subdomain.domain.comhtaccess HSTS 防止从 www.subdomain.domain.com 重定向到 subdomain.domain.com
【发布时间】：2021-12-28 06:25:36
【问题描述】：

我有一个网站，用户可以为该网站创建无限的子域。
我们的一位客户希望我们在标头上启用 HSTS，因此我在 .htaccess 中添加了以下规则：

Header set Strict-Transport-Security "max-age=63072000; includeSubDomains"

我们有一个通配符证书*.domain.com 来保护所有子域，因为我们不想为每个子域创建一个单独的证书。

问题是当有人要去www.subdomain.domain.com时，他们需要被重定向到subdomain.domain.com。
但 Chrome 正在阻止重定向，因为在 *.*.domain.com 级别上没有有效证书，并且 HSTS 规则使 Chrome 完全阻止重定向并出现 NET::ERR_CERT_COMMON_NAME_INVALID 错误。

.htaccess 中重要的部分：

RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1%{REQUEST_URI} [R=301,QSA,NC,L]

RewriteCond %{HTTPS} off
RewriteRule ^/?(.*) https://%{HTTP_HOST}%{REQUEST_URI} [NC,QSA,R=301,L]

Header set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header always set Cache-Control "no-store, no-cache, must-revalidate"

我原以为 www 到非 www 的重定向会首先出现，因为它在 .htaccess 文件中更高。

【问题讨论】：

mod_rewrite 和 mod_headers 是不同的模块，因此管理执行哪些 mod_rewrite 规则的规则不一定适用于其他模块。我认为您最好的选择是根据域使用 mod_rewrite 设置环境变量，并且仅在设置了该环境变量时才设置 HSTS。类似于：stackoverflow.com/questions/62559797/…
@Sumurai8 我认为最大的问题是一旦人们访问了 sub.domain.com 就设置了 HSTS，这很好，但是 www.sub.domain.com 现在也启用了 HSTS .而且我无法删除 includeSubdomains，因为 .htaccess 是为 domain.com 和 sub.domain.com 共享的

标签： apache .htaccess redirect subdomain hsts

【解决方案1】：

如果您不想在 www 子子域上启用 HSTS，则需要在标头周围放置 <If> 语句，并且不要在 HSTS 规则中使用 includeSubDomains。

如果 HSTS 的 Header 指令周围没有 <If "%{HTTP_HOST} != 'www.sub.example.com'>，则无论 .htaccess 文件中规则的顺序如何，都将为该子域发送该标头。

当您在 HSTS 规则中使用 includeSubDomains 时，www.sub.example.com 的 HSTS 将在您访问 sub.example.com 甚至 example.com 时启用。

现在您已经为该 www 子域启用了 HSTS，对于已经访问过您网站的浏览器，您无法撤销它。此时，您最好的做法是获取涵盖 www 子域的证书。您可能可以将 at 作为主题备用名称 (SAN) 添加到现有证书中。

【讨论】：

有很多子域，每天都会有更多/更少，所以添加它们会花费很多时间。我在上面进行了测试，但我认为这对我没有帮助，因为 sub.example.com 需要具有 HSTS，并且当我不包含 includeSubdomain 时，这些子域不再具有活动的 HSTS。简单说我想要从 www 重定向到非 www 高于一切，
我注意到在 Plesk 中 http 到 https 重定向已打开，因此我将其删除。当我访问http://www.sub.domain.com 时，我被重定向到https://sub.domain.com，网站可见。但是当我再次访问http://www.sub.domain.com 时，我将我重定向到https://www.sub.domain.com，我得到了HTST 错误
这是因为 HSTS 要求从 http 的重定向除了将 http 更改为 https 之外什么都不做。获得 HSTS 规则后，重定向将永远被忽略，即使没有重定向，HSTS 也会为您处理更改为 https。
也许您应该只在这个子域上启用 HSTS 并为其www. 子子域获取证书，而不是尝试为其他客户执行此操作。 HSTS 是一个好主意，但是当涉及到子域时，它会产生一些非常烦人的影响。（或者当您想在 Intranet 上使用私有子域时。）
这听起来确实是个不错的计划，所以这意味着我将 if 语句更改为 sub2.domain.com，并且只注册那个 www 证书？

【解决方案2】：

...HSTS 规则使 Chrome 完全阻止重定向并出现 NET::ERR_CERT_COMMON_NAME_INVALID 错误

这与 HSTS 无关。该错误是“因为*.*.domain.com 级别上没有有效证书”。在尝试实施 HSTS 之前，您会遇到同样的错误。（除非您只通过 HTTP 测试过 www 子子域？！）

没有捷径。如果您需要通过 HTTPS 访问 www 子子域，那么您需要一个涵盖该主机名的有效安全证书。

我原以为 www 到非 www 的重定向会首先出现，因为它在 .htaccess 文件中更高。

NET::ERR_CERT_COMMON_NAME_INVALID 是在 SSL 握手期间发生的浏览器错误。这一切都发生在之前 .htaccess 甚至被处理（在任何数据传输之前）。

旁白：虽然你真的需要一个 www 子域吗？

【讨论】：

它确实与 HSTS 有关，因为一旦浏览器获得 HSTS 规则，它就永远不会访问 HTTP 站点来查看重定向，并且总是会尝试使用 HTTPS 进行重定向。如果没有 HSTS，带有 www 的输入流量将使用 HTTP 重定向，但现在使用 HSTS，输入流量会直接转到 HTTPS。
至于真正需要www子子域，很多人随便加www。你真的需要它。我有一些没有 www 子域的子域，并且收到了许多抱怨，说在我启用它之前无法访问该站点。
是的，这里也一样，客户无论如何都在输入 www。 HSTS 必须与它有关，因为 HSTS 使您无法允许无效证书。通常，当未启用 HSTS 时，您会得到一个按钮，无论如何您都可以继续，这当然也是不好的做法。而且 HTSTS 确实让客户首先使用我不想要的 HTTPS。
我注意到在 Plesk 中 http 到 https 重定向已打开，因此我将其删除。当我访问http://www.sub.domain.com 时，我被重定向到https://sub.domain.com，网站可见。但是当我再次访问 http://www.sub.domain.com 时，我将我重定向到 https://www.sub.domain.com 并且我收到 HTST 错误