☰

Apache：非标准 HTTP 端口上的 HSTS 重定向导致 SSL 错误

tag-icon • tag-icon apache-2.4 hsts
Apache：非标准 HTTP 端口上的 HSTS 重定向导致 SSL 错误

我读了 SF 上的一些答案，但仍然没有找到解决方案。我的问题似乎有点特殊……

客户正在通过端口 81 访问网络服务器。随着 HTTPS 的普遍趋势，该服务已升级并安装在标准端口 443 上。对我的故事至关重要的是，新的 HTTPS 网站上启用了 HSTS。

在端口 81 上，我们放置了一个简单的 Apache 重定向：

ServerName example.com
RewriteEngine on
RewriteCond %{SERVER_NAME} =example.com
RewriteRule ^ https://example.com/ [END,NE,R=permanent]

成功了。访问http://example.com:81将自动重定向至https://example.com/

然而，由于 HSTS，它只能起作用一次。我猜想许多用户都是通过链接、书签、缓存的 Google 搜索访问的……然后被自动定向到http://example.com:81。甚至我的浏览器的自动完成功能仍然喜欢建议：81 链接，所以我猜我不是唯一的一个。

他们的浏览器具有有效的 HSTS 策略，会对不安全的请求执行内部升级，从而导致浏览器向https://example.com:81。由于 SSL 错误，无法加载 - 该端口未配置为 SSL 流量。

因此我需要一种方法来重定向http://example.com:81和https://example.com:81到https://example.com

我曾看到过 Webmin，通过以下方式访问http://example.com:10000给出有关网站在 HTTPS 上处于活动状态的自定义错误消息，该消息由 Webmin 生成，而不是浏览器生成。即使我可以让这样的页面加载并刷新<meta>到新的 URL，这仍然会让用户感到满意，而旧的 URL 会自行发挥作用并从链接、缓存等中删除。

答案1

我通过在端口 81 上启用 HTTPS 解决了这个问题。当请求 HTTP 版本时（即第一的在发出请求时，HSTS 才能覆盖该请求）。我将 Apache 配置为使用重定向来响应 400 错误：

ServerName example.com

Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

RewriteEngine on
RewriteCond %{SERVER_NAME} =example.com
RewriteRule ^ https://example.com/ [END,NE,R=permanent]

ErrorDocument 400 https://example.com/

这意味着首次请求将通过 400 错误重定向定向到 HTTPS 站点，而后续通过 HTTPS 对非标准端口的请求将通过 重定向RewriteRule。

对 HTTPS 端口发出的 HTTP 请求可能会显示服务器生成的错误（这就是 Webmin 可以显示“友好”错误消息的原因）。另一方面，对 HTTP 端口发出的 HTTPS 请求不会生成错误，因为浏览器永远不会建立通信通道。

相关内容