Discourse에서 'www' 사용법

제품 지원
21

아니요, 추가 설치할 것은 없습니다.

또한, 제가 추가해야 했던 유일한 블록은 다음과 같습니다:

  after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d mywebsite.org --keylength"

(nginx가 포함된 다른 두 개의 replace 블록 없이도 http에서 https로의 리다이렉트가 정상적으로 작동하는 것 같습니다)

22

드디어 시간을 내어 "여러 도메인으로 Let’s Encrypt 설정하기"와 “단일/여러 도메인을 Discourse 인스턴스로 리디렉션하기” 가이드를 모두 읽어 보았습니다.

컨테이너의 app.yml 파일에 여러분이 하신 것보다 훨씬 더 많은 내용을 추가했는데, 거의 모든 것이 정상적으로 작동합니다.

제 Discourse는 www. 서브도메인에 호스팅되어 있으며, 제 목표는 apex 도메인에서의 http 및 https 요청을 www 서브도메인으로 리디렉션하는 것이었습니다. 지금은 이것이 작동하지만, https://mydomain.com으로 이동하면 리디렉션은 수행되지만 Chrome 콘솔에 다음과 같은 경고가 표시됩니다:

Redirecting navigation example.com -> www.example.com because the server presented a certificate valid for www.example.com but not for example.com. To disable such redirects launch Chrome with the following flag: --disable-features=SSLCommonNameMismatchHandling

제 app.yml 추가 내용은 다음과 같습니다:

 after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d example.com -d www.example.com --keylength"
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /return 301 https.+/
        to: |
          return 301 https://$host$request_uri;
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /gzip on;[^\}]+\}/m
        to: |
          gzip on;
          add_header Strict-Transport-Security 'max-age=31536000'; # remember the certificate for a year and automatically connect to HTTPS for this domain
  after_web_config:
    - replace:
        filename: /etc/nginx/nginx.conf
        from: /sendfile.+on;/
        to: |
          server_names_hash_bucket_size 64;
          sendfile on;
    - file:
      path: /etc/nginx/conf.d/discourse_redirect_1.conf
      contents: |
        server {
          listen 80;
          listen 443 ssl;
          server_name example.com;
          return 301 https://www.example.com$request_uri;
        }

이것이 올바르게 보입니까? 그렇다면 인증서 이름 불일치 문제에 대한 해결책이 있을까요?

수정: www 서브도메인을 위한 A 레코드와 apex 도메인으로의 모든 요청을 잡아내는 @를 사용하는 A 레코드 두 개를 가지고 있습니다. 둘 다 제 Digital Ocean 드롭렛 IP를 가리킵니다. 이것도 올바른 설정이라고 가정해도 될까요?

감사합니다.

23

Cloudflare가 도메인 등록사가 아니더라도 무료로 구현할 수 있습니다. HTTPS와 호환되며, Discourse 설치에 추가적인 복잡성을 전혀 더하지 않습니다.

24

감사합니다. 저는 현재 Cloudflare를 사용하지 않고 있어서 이전에 해당 내용을 접해본 적이 없었습니다. 다른 경로를 통해 위의 가이드를 따랐고, 대부분 문제를 해결할 수 있었습니다. 제가 위에 답변을 제출한 바로 그 시점에 게시물을 올리셨네요.

25

이 웹사이트를 확인해 주시겠습니까? 필요한 모든 리디렉션이 포함되어 있나요? 이는 오직 하나의 replace 블록(위 참조)과 이 DNS 설정으로 이루어져 있습니다(이메일 TXT 레코드만 삭제했습니다):

image
image1421×550 14.9 KB

콘솔에서 경고 메시지가 표시되지 않습니다.

26

네, 다만 Let’s Encrypt 구성이 변경될 때 문제가 발생할 수 있다는 점에 대비해 두세요.

Let’s Encrypt가 타원 곡선(elliptical curve)을 지원하도록 업데이트되었을 때, 위에서 언급한 접근 방식은 몇 주 동안 작동하지 않았습니다.

28

유일한 차이는 제 DNS에 CAA 레코드가 없다는 점입니다. 사용하신 값과 동일한 값을 추가하겠습니다.

귀하의 discourse 호스트명이 www.example.com이라고 가정할 때, https://example.com에 액세스할 때 경고가 표시되지 않는다고 확신하십니까?

Chrome for Android에서는 경고가 더욱 심각하며, 사이트가 완전히 차단되고 리다이렉트도 되지 않습니다.

29

이제 좀 이해가 안 되네요 :slight_smile: 어떤 점에 주의해야 하고, 뭘 고쳐야 할지 준비해야 하나요?

30

맞습니다.

네, 콘솔에 경고가 표시되지 않습니다.

31

문제를 찾은 것 같습니다. 원래 이렇게 되어 있었습니다:

after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d example.com -d www.example.com --keylength"

아래와 같이 되어 있어야 했습니다:

after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d example.com --keylength"

마지막 줄을 주목해 보세요. 저는 example.com과 www.example.com을 모두 포함하고 있었습니다.

또한 return 301 https://$host$request_uri;를 return 301 $scheme://$host$request_uri;로 변경하고 다시 빌드한 후, 이제 제대로 작동하는 것 같습니다.

지금 @Stephen이 letsencrypt 구성이 변경될 경우 문제가 생길 수 있다고 언급한 부분이 걱정되네요.

32

작년 9월 9일에 이루어진 변경 사항으로 인해 현재 따르고 계신 접근 방식이 깨졌고, 해당 구현이 표준 설치 범위를 벗어나는 관계로 10월 31일에야 해결책이 공개되었습니다. 따르셨던 주제와 위키의 편집 이력을 확인해 보시면 명확하게 기록되어 있는 것을 보실 수 있습니다.

추가 구성을 직접 깊이 파고들어야 하는 상황이 아니므로, 그렇게 하는 것을 권장하지 않습니다. 반면, Let’s Encrypt가 실제로 변경되어 영향을 받는 경우라면 이 주제로 다시 안내해 드릴 수 있습니다.