Set up Let’s Encrypt with multiple domains / redirects

[brahn]

NOTE: @pfaffman says: This page needs to be cleaned up. There is now a new ENV setting that will let you add more hostnames. In your app.yml under your DISCOURSE_HOSTNAME line (it can go many places but that one makes sense), add

 DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com

and early reports suggest that you’ll get valid certs for those domains and that accessing https://domain.com will properly redirect you to your DISCOURSE_HOSTNAME without a certificate error.

If you do that and it works for you, you might add another “me too!” post to the bottom. If you feel comfortable, you could also edit this first post with the instructions that you think would be most helpful.

---

This is to address the problem where you get certificate errors with any redirects or CNAME DNS entries which point to your actual installed Discourse (sub)domain.

If you do not have https configured already (you do if you have done a standard install recently) see Setting up Let’s Encrypt as your first step.

Legacy Method

The method below no longer reliably works as of August 2025

There are three patterns that need to be replaced. Enter your (sub)domain (and any additional subdomains preceded by -d ) and then add the following to your app.yml hooks section (towards the end of the file):

2025-04-23 @pfaffman changed the code because there’s a 3rd place it needs to be changed

  after_ssl:
    - replace:
        filename: /etc/runit/1.d/letsencrypt
        from: /-d =domain1= /
        to: "-d =domain1= -d =domain2= "
        global: true

This will allow you to have HTTPS configured for a second domain that will redirect to the correct one without certificate issues.

If you need to add multiple extra domains, you can enter something like this in the domain2 field: www.bananas.com -d forum.bananas.com

For example, if you want people who visit https://forum.example.com to be redirected to your forum at https://community.example.com without a certificate error, this is all you need.

[Rhod (Rodolfo)]

감사합니다. "www.example.com"를 "comunnity.example.com"으로 리디렉션하려면 이렇게 하면 되나요?
아니면 어떻게 해야 하나요?
www.example.com 도메인에 문제가 있어서 DNS를 comunnity.example.com으로 리디렉션하도록 설정했지만 Firefox나 Chrome에서는 작동하지 않습니다.

[JimPas]

리디렉트를 확인하는 리디렉트 체크 도구가 있습니다.

[merefield (Robert)]

이 문제에 대해 좀 고전하고 있습니다. 아니, 꽤 많이 고전하고 있죠.

사이트 중 하나에 CDN을 추가하는 실험을 하기로 결정했습니다.

문서를 읽은 후, Fastly가 권장하는 기준(그리고 그렇게 하라는 일반적인 조언)을 충족시키기 위해 현재 최상위 도메인(apex domain)에서 서브도메인으로 사이트를 이동하는 것이 더 낫다는 것을 깨달았습니다.

그래서 "음, 이건 쉬울 텐데, 전에 해본 적 있으니까…"라고 생각했습니다. 정말이었나요?

해당 사이트는 https://starzen.space 입니다.

저희는 이 가이드를 사용하여 이번 주말에 사이트를 https://www.starzen.space 로 이동했습니다.

모두 순조롭게 진행되었지만, 물론 이 사이트를 통해 지금까지 확보한 소수의 사용자들을 고려해야 하므로 리다이렉트를 추가하고 싶었습니다.

제 이해로는 원래 링크에도 인증서가 발급되어야 하므로, 이 가이드(예전에는 훨씬 더 복잡했었나요?)를 따라 app.yml에 다음 내용을 추가했습니다:

hooks:
  after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d starzen.space --keylength"
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /return 301 https.+/
        to: |
          return 301 https://$host$request_uri;
  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 starzen.space;
            return 301 $scheme://www.starzen.space$request_uri;
          }

재빌드 시 모든 것이 정상적으로 진행되는 것처럼 보입니다.

그러나 브라우저로 https://starzen.space 에 접속을 시도하면 다음과 같은 화면이 나타납니다:

curl을 실행하면:

blah discourse % curl https://starzen.space
curl: (60) SSL: no alternative certificate subject name matches target host name 'starzen.space'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

인증서가 문제인 것 같다고 확신합니다. 왜냐하면 동일한 명령을 보안 무시 모드(insecure mode)로 실행하면 다음과 같은 결과가 나오기 때문입니다:

blah discourse % curl -k https://starzen.space
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.21.6</center>
</body>
</html>

이것이 제가 원하는 결과라고 생각합니다.

수정된 스크립트 파일이 올바른 것 같습니다. 현재 가지고 있는 내용은 다음과 같습니다:

root@starship-enterprise:/etc/runit/1.d# cat letsencrypt 
#!/bin/bash
/usr/sbin/nginx -c /etc/nginx/letsencrypt.conf

issue_cert() {
  LE_WORKING_DIR="${LETSENCRYPT_DIR}" /shared/letsencrypt/acme.sh --issue $2 -d www.starzen.space -d starzen.space --keylength $1 -w /var/www/discourse/public
}

cert_exists() {
  [[ "$(cd /shared/letsencrypt/www.starzen.space$1 && openssl verify -CAfile <(openssl x509 -in ca.cer) fullchain.cer | grep "OK")" ]]
}

########################################################
# RSA cert
########################################################
issue_cert "4096"

if ! cert_exists ""; then
  # Try to issue the cert again if something goes wrong
  issue_cert "4096" "--force"
fi
<SNIP>

컨테이너 내부에서 명령줄을 통해 이 스크립트를 직접 실행해 보기도 했습니다. 실행하기 전에 이중 도메인에 대한 올바른 명령이 실행되도록 대상 디렉터리에서 모든 인증서 파일을 백업 디렉터리로 이동했습니다:

root@starship-enterprise:/etc/runit/1.d# ./letsencrypt 
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] still could not bind()
[Sun 25 Sep 2022 05:50:04 PM UTC] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Sun 25 Sep 2022 05:50:04 PM UTC] Creating domain key
[Sun 25 Sep 2022 05:50:05 PM UTC] The domain key is here: /shared/letsencrypt/www.starzen.space/www.starzen.space.key
[Sun 25 Sep 2022 05:50:05 PM UTC] Multi domain='DNS:www.starzen.space,DNS:starzen.space'
[Sun 25 Sep 2022 05:50:05 PM UTC] Getting domain auth token for each domain
[Sun 25 Sep 2022 05:50:08 PM UTC] Getting webroot for domain='www.starzen.space'
[Sun 25 Sep 2022 05:50:08 PM UTC] Getting webroot for domain='starzen.space'
[Sun 25 Sep 2022 05:50:08 PM UTC] www.starzen.space is already verified, skip http-01.
[Sun 25 Sep 2022 05:50:08 PM UTC] Verifying: starzen.space
[Sun 25 Sep 2022 05:50:12 PM UTC] Pending
[Sun 25 Sep 2022 05:50:15 PM UTC] Success
[Sun 25 Sep 2022 05:50:15 PM UTC] Verify finished, start to sign.
[Sun 25 Sep 2022 05:50:15 PM UTC] Lets finalize the order.
[Sun 25 Sep 2022 05:50:15 PM UTC] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/590255196/128806215177'
[Sun 25 Sep 2022 05:50:16 PM UTC] Downloading cert.
[Sun 25 Sep 2022 05:50:16 PM UTC] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/03ff6b1b76f8516165032c6c2e02205a529b'
[Sun 25 Sep 2022 05:50:17 PM UTC] Cert success.
-----BEGIN CERTIFICATE-----
Lotsofcrazytext
-----END CERTIFICATE-----
[Sun 25 Sep 2022 05:50:17 PM UTC] Your cert is in  /shared/letsencrypt/www.starzen.space/www.starzen.space.cer 
[Sun 25 Sep 2022 05:50:17 PM UTC] Your cert key is in  /shared/letsencrypt/www.starzen.space/www.starzen.space.key 
[Sun 25 Sep 2022 05:50:17 PM UTC] The intermediate CA cert is in  /shared/letsencrypt/www.starzen.space/ca.cer 
[Sun 25 Sep 2022 05:50:17 PM UTC] And the full chain certs is there:  /shared/letsencrypt/www.starzen.space/fullchain.cer 
[Sun 25 Sep 2022 05:50:17 PM UTC] Installing key to:/shared/ssl/www.starzen.space.key
[Sun 25 Sep 2022 05:50:17 PM UTC] Installing full chain to:/shared/ssl/www.starzen.space.cer
[Sun 25 Sep 2022 05:50:17 PM UTC] Run reload cmd: sv reload nginx
ok: run: nginx: (pid 579) 35281s
[Sun 25 Sep 2022 05:50:17 PM UTC] Reload success
[Sun 25 Sep 2022 05:50:18 PM UTC] Domains not changed.
[Sun 25 Sep 2022 05:50:18 PM UTC] Skip, Next renewal time is: Wed 23 Nov 2022 10:01:01 AM UTC
[Sun 25 Sep 2022 05:50:18 PM UTC] Add '--force' to force to renew.
[Sun 25 Sep 2022 05:50:18 PM UTC] Installing key to:/shared/ssl/www.starzen.space_ecc.key
[Sun 25 Sep 2022 05:50:18 PM UTC] Installing full chain to:/shared/ssl/www.starzen.space_ecc.cer
[Sun 25 Sep 2022 05:50:18 PM UTC] Run reload cmd: sv reload nginx
ok: run: nginx: (pid 579) 35282s
[Sun 25 Sep 2022 05:50:18 PM UTC] Reload success

거의 성공적으로 끝났습니다!!! 이제 curl은 훨씬 더 친절해져서 리다이렉트를 반환해 줍니다:

blah discourse % curl https://starzen.space
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.21.6</center>
</body>
</html>

그리고 Firefox 및 Chrome에서 https://starzen.space 는 이제 정상적으로 작동하여 올바른 서브도메인으로 리다이렉트됩니다. 하지만 여전히 Safari에서는 그 끔찍한 오류 화면이 나타납니다. 무슨 일이죠? 사이트 재시작도 하고 이 사이트의 캐시도 비웠는데 말이죠:

브라우저에서 인증서를 확인해 보니 다음과 같습니다:

[pfaffman (Jay Pfaffman)]

이 문제를 좀 더 자세히 살펴볼 생각이었다. 이제 Let’s Encrypt 템플릿에서 추가 도메인을 입력해야 하는 곳이 두 곳인 것 같다. Nginx 설정은 변경할 필요가 없을 것 같다. 호스트네임이 아닌 모든 요청에 대해 이미 301 리다이렉트를 수행하고 있기 때문이다.

해야 할 일은 Let’s Encrypt 템플릿을 확인하여 호스트네임을 어디에 설정하고 있는지 살펴본 후, 추가 호스트네임도 동일한 방식으로 설정하는 것이다.

[merefield (Robert)]

@pfaffman

호스트명이 아닌 모든 요청에 대해 이미 301 리다이렉트를 수행하고 있으므로 nginx 설정을 변경할 필요가 없다고 생각합니다.

네, 감사합니다. 완전성을 위해 그렇게 했는데, 아직까지 이로 인한 해로움은 보이지 않습니다. 하지만 언젠가 이를 제외하고 다시 구축하는 것도 괜찮습니다.

@pfaffman

해야 할 일은 Let’s Encrypt 템플릿을 살펴보고 호스트명이 어디에 배치되는지 확인한 후, 추가 호스트명에도 동일한 처리가 되고 있는지 확인하는 것입니다.

암호화 파일이 두 세트로 나뉘어 있는 것 같습니다?:

root@starship-enterprise:/shared/letsencrypt# cd starzen.space
root@starship-enterprise:/shared/letsencrypt/starzen.space# ls
backup	ca.cer	fullchain.cer  starzen.space.cer  starzen.space.conf  starzen.space.csr  starzen.space.csr.conf  starzen.space.key
root@starship-enterprise:/shared/letsencrypt/starzen.space# cd ..
root@starship-enterprise:/shared/letsencrypt# cd www.starzen.space
root@starship-enterprise:/shared/letsencrypt/www.starzen.space# ls
backup	    ca.cer	   www.starzen.space.cer   www.starzen.space.csr       www.starzen.space.key
backup_two  fullchain.cer  www.starzen.space.conf  www.starzen.space.csr.conf
root@starship-enterprise:/shared/letsencrypt/www.starzen.space# 

아, 여기(그리고 아래)일까요?

templates/web.letsencrypt.ssl.template.yml

호스트명 정보만 포함되고, 아펙스 도메인(apex)은 포함되지 않는 것 같습니다.

[merefield (Robert)]

아니요, 저는 이것이 올바른 것 같습니다. 인증서는 하나여야 하며, www.와 아펙스 도메인 모두에서 작동해야 합니다.

이 도구는 공개 인증서에 도메인이 하나만 있다고 제안하고 있습니다(이것이 문제의 원인일까요?):

SSLCheck

[pfaffman (Jay Pfaffman)]

Let’s Encrypt에서 인증서를 가져오는 부분을 수정해야 합니다. 두 도메인에 대한 단일 인증서를 요청하도록 해야 합니다. 이 지침은以前 잘 작동했지만, 인증서 요청 방식이 변경된 것 같습니다. 올바른 인증서를 가져오면 나머지는 모두 정상적으로 작동합니다.

[JimPas]

certbot certificates를 실행하면 현재 인증서와 해당 인증서가 적용된 도메인을 확인할 수 있습니다. 인증서가 아펙스 도메인과 www 도메인을 모두 포함하지 않는 경우, 다음 두 가지 방법 중 하나를 선택할 수 있습니다.

1. certbot을 다시 실행하여 아펙스 도메인과 www 도메인을 모두 포함하는 인증서를 생성합니다.

이 옵션을 선택한 경우, 삭제할 인증서의 이름을 확인하기 위해 certbot certificates를 실행합니다. 그런 다음 certbot delete (삭제할 인증서 이름)을 실행합니다. 이 작업을 완료하면 아펙스와 www가 모두 포함된 새 인증서만 남게 됩니다.

또는 (가장 쉬운 방법)

2. certbot --expand -d existing.domain -d added.domain을 실행합니다.

이 명령은 기존 도메인과 -d 플래그를 통해 추가한 도메인을 모두 포함하는 새 인증서로 기존 인증서를 업데이트합니다.

[merefield (Robert)]

@JimPas

certbot 인증서

Jim, certbot 명령을 찾을 수 없다는 건가요? 표준 설치에 포함된 건데 단순히 경로 문제인 건가요?

[pfaffman (Jay Pfaffman)]

실제로 확인해 보진 않았지만… 보통은 certbot을 사용하는 걸로 알고 있어요. 그런데 컨테이너 안에서는 discourse가 acme를 사용했더라고요.

그리고 관련해서, 이걸 컨테이너 안에서 시도하고 계신 건가요, 아니면 밖에서?

(오늘도 일정이 점점 꽉 차서, 처음 생각했던 만큼 꼼꼼히 살펴볼 수 없을 수도 있을 것 같아요. 하지만 제 할 일 목록에는 올려 두었습니다.)

[merefield (Robert)]

동의합니다 … 제가 생각하기에 이렇게 하는 방법이 하나 있네요?:

적합한 리눅스 명령줄에서 다음을 사용했을 때

true | openssl s_client -connect www.starzen.space:443 2>/dev/null \
| openssl x509 -noout -text \
| perl -l -0777 -ne '@names=/\bDNS:([^\s,]+)/g; print join("\n", sort @names);'

도메인이 하나만 표시되고, 아펙스 도메인이 빠져 있습니다.

[pfaffman (Jay Pfaffman)]

컨테이너 내부에서 인증서를 요청(및 갱신?)하는 코드를 확인하면, 두 도메인 모두에 대해 인증서를 요청하고 있음을 알 수 있습니다.

[merefield (Robert)]

네, 맞습니다. 아래 내용과 같습니다:

LE_WORKING_DIR="${LETSENCRYPT_DIR}" /shared/letsencrypt/acme.sh --issue $2 -d www.starzen.space -d starzen.space --keylength

위 로그 출력에서도 이를 확인할 수 있습니다.

다만, -d www.starzen.space만 포함된 다른 인증서 설치 단계들이 있어 문제가 될 수 있습니다. 물론 이 인증서가 두 도메인 모두를 위해 생성된 것이라면, 그것이 문제가 아닐 수도 있지만요…

[pfaffman (Jay Pfaffman)]

@merefield

그러나 -d www.starzen.space만 포함된 다른 인증서 설치 단계들이 있는데, 이것이 문제가 될 수 있지 않을까요?

제가 계속 말하고 있던 바로 그 부분입니다. 그것들도 업데이트해야 하는 것 같습니다. 왜 지금은 여러 개가 있는지 모르겠지만, OP(첫 번째 게시글)에는 그 모든 단계를 변경하기 위한 코드가 업데이트되어야 합니다. 그렇게 생각합니다.

[merefield (Robert)]

네, 일단 수동으로 시도해볼게요.

[pfaffman (Jay Pfaffman)]

아, 좋다. 바로 내가 하려던 거였어. 아마 너를 속여서 하게 만든 거겠지.

[merefield (Robert)]

시도하는 건 합리적인데, nano를 설치하려면 컨테이너를 다시 빌드해야 할 수도 있겠네요 …

[pfaffman (Jay Pfaffman)]

아니요!

 apt-get uodate;apt-get install nano

그냥 컨테이너 안에서 실행하면 됩니다. 저는 항상 그렇게 합니다 (다만 저는 vim을 사용하지만요).

[merefield (Robert)]

불행히도 그 방법은 작동하지 않았습니다:

root@starship-enterprise:/etc/runit/1.d# ./letsencrypt 
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] still could not bind()
[Mon 26 Sep 2022 12:35:54 PM UTC] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Mon 26 Sep 2022 12:35:54 PM UTC] Creating domain key
[Mon 26 Sep 2022 12:35:56 PM UTC] The domain key is here: /shared/letsencrypt/www.starzen.space/www.starzen.space.key
[Mon 26 Sep 2022 12:35:56 PM UTC] Multi domain='DNS:www.starzen.space,DNS:starzen.space'
[Mon 26 Sep 2022 12:35:56 PM UTC] Getting domain auth token for each domain
[Mon 26 Sep 2022 12:35:59 PM UTC] Getting webroot for domain='www.starzen.space'
[Mon 26 Sep 2022 12:35:59 PM UTC] Getting webroot for domain='starzen.space'
[Mon 26 Sep 2022 12:35:59 PM UTC] www.starzen.space is already verified, skip http-01.
[Mon 26 Sep 2022 12:35:59 PM UTC] starzen.space is already verified, skip http-01.
[Mon 26 Sep 2022 12:36:00 PM UTC] Verify finished, start to sign.
[Mon 26 Sep 2022 12:36:00 PM UTC] Lets finalize the order.
[Mon 26 Sep 2022 12:36:00 PM UTC] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/590255196/129044627717'
[Mon 26 Sep 2022 12:36:01 PM UTC] Downloading cert.
[Mon 26 Sep 2022 12:36:01 PM UTC] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/03ffc90cecd2f11f2ba386da2d501127aee5'
[Mon 26 Sep 2022 12:36:02 PM UTC] Cert success.
-----BEGIN CERTIFICATE-----
phewbigcert
-----END CERTIFICATE-----
[Mon 26 Sep 2022 12:36:02 PM UTC] Your cert is in  /shared/letsencrypt/www.starzen.space/www.starzen.space.cer 
[Mon 26 Sep 2022 12:36:02 PM UTC] Your cert key is in  /shared/letsencrypt/www.starzen.space/www.starzen.space.key 
[Mon 26 Sep 2022 12:36:02 PM UTC] The intermediate CA cert is in  /shared/letsencrypt/www.starzen.space/ca.cer 
[Mon 26 Sep 2022 12:36:02 PM UTC] And the full chain certs is there:  /shared/letsencrypt/www.starzen.space/fullchain.cer 
[Mon 26 Sep 2022 12:36:02 PM UTC] Installing key to:/shared/ssl/www.starzen.space.key
[Mon 26 Sep 2022 12:36:02 PM UTC] Installing full chain to:/shared/ssl/www.starzen.space.cer
[Mon 26 Sep 2022 12:36:02 PM UTC] Run reload cmd: sv reload nginx
ok: run: nginx: (pid 2970) 329s
[Mon 26 Sep 2022 12:36:02 PM UTC] Reload success
[Mon 26 Sep 2022 12:36:03 PM UTC] Domains not changed.
[Mon 26 Sep 2022 12:36:03 PM UTC] Skip, Next renewal time is: Wed 23 Nov 2022 10:01:01 AM UTC
[Mon 26 Sep 2022 12:36:03 PM UTC] Add '--force' to force to renew.
[Mon 26 Sep 2022 12:36:04 PM UTC] Installing key to:/shared/ssl/www.starzen.space_ecc.key
[Mon 26 Sep 2022 12:36:04 PM UTC] Installing full chain to:/shared/ssl/www.starzen.space_ecc.cer
[Mon 26 Sep 2022 12:36:04 PM UTC] Run reload cmd: sv reload nginx
ok: run: nginx: (pid 2970) 331s
[Mon 26 Sep 2022 12:36:04 PM UTC] Reload success

여전히 단일 도메인만 포함된 인증서가 노출된 것으로 보입니다 …

true | openssl s_client -connect www.starzen.space:443 2>/dev/null \
| openssl x509 -noout -text \
| perl -l -0777 -ne '@names=/\bDNS:([^\s,]+)/g; print join("\n", sort @names);'
www.starzen.space