www 없이 LetsEncrypt는 작동하지만 www 포함 시 작동하지 않음

제품 지원
1

누군가 조언을 해줄 수 있기를 바랍니다. 그러면 정말 고마울 것입니다. 상황을 설명하겠습니다.

저는 도메인 hostballs[.]com에 여러 번 Discourse를 설치해 보았습니다. 매번 www[.]hostballs[.]com으로 접속하면 hostballs[.]com으로 깔끔하게 리디렉션됩니다. 이는 Let’s Encrypt 인증서가 www가 있는 경우와 없는 경우 모두를 커버하기 때문입니다. 이것이 Discourse의 LE 구현에서 기본적으로 제공되는 표준 동작이라고 알고 있습니다.

현재, 제 새로운 Discourse 설치에서는 비-www 사이트(구성된 URL)에 대해 SSL을 설정하지만, www는 포함하지 않습니다. 즉, www[.]hostballs[.]com으로 접속하는 사용자는 리디렉션되지 않고 SSL 오류를 확인하게 됩니다. 기본 동작이 이와 다르다는 것을 알고 있고, Discourse의 설치 과정이 너무 제어되어 있어서 certbot으로 가서 수동으로 모든 작업을 시작하고 싶지 않습니다(그렇게 하면 정기적인 업데이트가 얼마나 재미있을지 모르겠네요), 앞으로 나아갈 최선의 경로가 무엇인지 확신이 서지 않습니다.

이 문제를 해결하는 동안 app.yml에서 ssl과 LE 템플릿, 그리고 LE 이메일 주석을 처리했습니다. 그런 다음 /shared/standalone에서 letsencrypt와 ssl 디렉토리를 삭제했습니다. SSL 없이 사이트를 다시 빌드한 후, app.yml에서 해당 옵션을 다시 활성화하고 SSL 인증서/설정을 생성하기 위해 다시 빌드했습니다. 이 과정은 성공했지만, www 문제는 여전히 해결되지 않았습니다.

유사한 상황을 겪어 보고 해결책을 찾은 분이 있으신가요?

2

물론입니다! 이 작업은 약간 더 필요하지만, 단순하며 매우 일반적인 사용 사례입니다. 아래를 참고하세요:

그리고:

3

위 조언이 부담스럽게 느껴진다면, 간단한 DNS 리디렉션을 설정하는 것도 좋은 방법입니다. 대부분의 도메인 등록사가 이 기능을 제공합니다.

Discourse는 여러 URL로 동시에 게시할 수 없으며, 루트 레코드(www가 아닌 주소)와 www ‘a’ 레코드는 서로 다른 주소를 가리킵니다. 사이트에 사용할 FQDN을 지정하면, 나머지 추가 주소는 리디렉션으로 처리해야 합니다.

4

이미 제공된 제안 두 가지 모두 마음에 들지 않는다면, www.example.com을 사용하고 http://forcewww.com/을 통해 www 사이트로 리디렉션할 수 있습니다.

5

친구 여러분, 감사합니다. 미래에 다른 분들에게 도움이 될 수 있는 몇 가지 세부 사항을 정리해 보겠습니다.

이 문제는 한 사용자가 www로 접속이 되지 않고 인증서 오류가 발생한다고 알려주면서 시작되었습니다. 해당 사용자가 보고 스레드에서 제공한 https 링크에 직접 접속해 보니 저 역시 동일한 문제를 겪었습니다. 과거에는 www를 사용했을 때 같은 문제가 발생하지 않았고, 대신 루트 도메인으로 문제없이 리다이렉트되었습니다. 이로 인해 최근 마이그레이션 후 제 설치 환경이 어딘가 깨져서 새로운 Discourse 설치의 기본 동작 방식대로 작동하지 않는다고 결론 내렸습니다.

그래서 루트 도메인을 사용할 때 기본적으로 www가 작동하는지 증명하기 위해 새 도메인에 Discourse를 새로 설치했습니다. 해당 도메인에 접속한 후, 주소창의 URL을 편집하여 앞에 "www."를 추가했습니다. 예상대로 루트 도메인으로 문제없이 리다이렉트되었습니다. 그러고 나서 한 가지를 더 시도해 보기로 했습니다. URL 앞에 "https://"를 수동으로 입력해 보았습니다. 그러자 동일한 인증서 오류가 발생했습니다.

따라서 Discourse의 LE(Let’s Encrypt) 구현에서 www 서명이 기본 동작이라고 생각하게 된 이유는, 실제로는 주소창에서 URL을 다시 작성하는 동안 브라우저가 포트 80을 기본값으로 사용하면서 http/https 부분을 내게 숨겼기 때문일 수 있습니다.

적어도 현재로서는 이것이 제가 파악한 상황의 최선의 평가입니다.

6

네, 서버 IP에 80 포트로 들어오는 모든 요청은 HTTPS를 통해 실제 FQDN으로 리디렉션되며, www는 특별한 경우가 아닙니다.

7

루트 도메인을 사용하고 www를 Let’s Encrypt로 서명하여 올바른 HTTPS 리디렉션을 수행하되, 과도하게 복잡하게 만들거나 리디렉션을 관리하기 위해 다른 웹 서버를 사용하지 않으려는 사용자에게 가장 간단한 해결 방법:

다음 부분을:

issue_cert() {
LE_WORKING_DIR=“${LETSENCRYPT_DIR}” $$ENV_LETSENCRYPT_DIR/acme.sh --issue $2 -d $$ENV_DISCOURSE_HOSTNAME --keylength $1 -w /var/www/discourse/public
}

다음으로 변경하세요:

issue_cert() {
LE_WORKING_DIR=“${LETSENCRYPT_DIR}” $$ENV_LETSENCRYPT_DIR/acme.sh --issue $2 -d $$ENV_DISCOURSE_HOSTNAME -d www.$$ENV_DISCOURSE_HOSTNAME --keylength $1 -w /var/www/discourse/public
}

변경할 파일:
/var/discourse/templates/web.letsencrypt.ssl.template.yml

그리고 당연히:

./var/discourse/launcher rebuild app

8

그것은 해결책이 아닙니다. 템플릿이 업데이트될 때마다 변경 사항이 사라지기 때문에, 그 이유만으로 권장되지 않습니다.

컨테이너 내부의 파일을 수정하려면 app.yml에서 훅(hooks)을 사용하세요.

9

음, 업데이트 시 깨질 가능성이 없는 방식으로 구현하는 방법을 찾지 못하겠습니다. 이건 커뮤니티를 위해 전용 도메인을 사용하면서 불필요한 서브도메인을 싫어하는 사람들이 겪는 고충인 것 같습니다.

물론 다른 곳에 별도의 웹 서버를 실행하는 경우를 제외하고는요.

10

검색을 사용한다면 인증서 등록을 수정하는 가이드가 이미 존재합니다.

11

네, 이미 한 가지 시도를 확인했는데, 파일이 변경되면서 중단되었고, 이로 인해 app.yml에서 파일을 변경하도록 설정해 둔 방식이 깨졌습니다:

파일을 직접 편집하든, 아니면 app.yml이 나중에 편집하게 하든, 업데이트는 해당 파일을 변경하여 편집 방식을 깨뜨릴 수 있습니다.

12

제가 하고 싶은 말은, 그 템플릿에 어떤 변경 사항이든 들어가면 다시 깨진다는 것입니다. 지난 몇 년간 PUPS/hooks 메서드를 깨뜨린 변경 사항은 단 하나뿐인데, 바로 ECC 지원의 도입이었습니다.