こんにちは。
標準のインストールを使用しています。
app.yml で次のように変更しました。
hooks:
## Add Let's Encrypt cert for non-www and www domain name
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.com -d www.example.com --keylength"
Discourse のホスト名は次のとおりです: www.example.com
これまでのところ、セットアップは正常に機能しており、証明書は example.com および www.example.com に対して配信されています。
しかし、SSLLabs で SSL パラメータを確認すると、www.example.com ドメインで HSTS ヘッダーが欠落しています。example.com では機能しています。
Strict Transport Security (HSTS) Yes
max-age=31536000; includeSubdomains; preload
そして、Hardenize (www.hardenize.com) は次のように述べています。
Redirection from HTTP to HTTPS not to the same host
When HSTS is used, the plaintext port should redirect to the HTTPS variant of the same hostname. This approach ensures that HSTS is enabled on that hostname, even if later the client is sent elsewhere. A redirection to another host is only safe if it is for a parent host that has HSTS with includeSubDomains enabled, but that’s not the case here.
Starting point:
http://example.deCurrent redirection:
https://www.example.comExpected redirection:
https://example.com
Policy not preloaded
When hostname is preloaded, that means that browsers embed your HSTS policy and apply it even to the first request sent to your web site. This server indicates preloading in its policy, but the domain name isn’t actually preloaded. We classify this as a warning because it’s a common problem to place the ‘preload’ keyword in the policy even though the infrastructure is not ready for preloading. This is dangerous because, in this situation, anyone can submit this domain name for preloading just by visitinghstspreload.org.We recommend that you either preload this domain name yourself—if it’s ready—or remove the preloading indicator from the policy until it is ready.
HSTS ヘッダーが www.example.com ドメインに設定されていない理由について、何かアイデアはありますか?