안녕하세요,
표준 설치 방식을 사용하고 있습니다.
app.yml에서 수정한 내용은 다음과 같습니다:
hooks:
## 비-www 및 www 도메인 이름에 Let's Encrypt 인증서 추가
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)는 다음과 같이 보고합니다:
HTTP에서 HTTPS로의 리디렉션이 동일한 호스트로 이루어지지 않음
HSTS가 사용될 때, 평문 포트는 동일한 호스트명의 HTTPS 버전으로 리디렉션해야 합니다. 이 접근 방식은 나중에 클라이언트가 다른 곳으로 이동하더라도 해당 호스트명에서 HSTS가 활성화되어 있음을 보장합니다. HSTS에 includeSubDomains가 활성화된 상위 호스트로 리디렉션되는 경우에만 안전하지만, 여기서는 해당 사항이 아닙니다.
시작 지점:
http://example.de현재 리디렉션:
https://www.example.com기대되는 리디렉션:
https://example.com
정책이 사전 로드되지 않음
호스트명이 사전 로드(preloaded)되었다는 것은 브라우저가 HSTS 정책을 내장하여 웹사이트로 전송되는 첫 번째 요청에도 이를 적용한다는 의미입니다. 이 서버는 정책에 사전 로드를 표시하고 있지만, 실제 도메인 이름은 사전 로드되어 있지 않습니다. 인프라가 사전 로드를 지원하지 못하는 상황에서 정책에 ‘preload’ 키워드를 넣는 것은 흔한 문제이므로 우리는 이를 경고로 분류합니다. 이는 위험한 상황으로, 이 경우 누구든hstspreload.org를 방문하기만 하면 이 도메인 이름을 사전 로드용으로 제출할 수 있기 때문입니다. 사전 로드가 준비되었다면 해당 도메인 이름을 직접 사전 로드하거나, 준비가 될 때까지 정책에서 사전 로드 표시를 제거할 것을 권장합니다.
www.example.com 도메인에 대해 HSTS 헤더가 설정되지 않는 이유가 무엇일까요? 아이디어가 있으신가요?