# Let's Encrypt 인증서 갱신(갑자기) 실패
**URL:** https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071
**Category:** Self-hosting
**Created:** [12월 24, 2021, 6:20오후 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071 "2021-12-24T18:20:14Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@L30110](https://meta.discourse.org/u/L30110)
#### Post date: [12월 24, 2021, 6:20오후 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/1 "2021-12-24T18:20:15Z")
얼마 전 – 정확히 얼마나 오래되었는지는 불분명하지만 적어도 몇 개월은 지났습니다 – 수년간 정상적으로 작동하던 제 Discourse 포럼에서 Let’s Encrypt 갱신이 실패하기 시작했습니다. 며칠 전 처음 이 문제를 인지했을 당시, 인증서는 2021년 8월에 만료된 상태였습니다. 수동으로 갱신을 시도하고 nginx를 재시작한 후, 인증서가 며칠 전에 만료된 것으로 갱신되었음을 발견했습니다. 물론 여전히 유효한 인증서는 아닙니다. Discourse 컨테이너 내에서 acme.sh를 수동으로 실행하여 강제 갱신을 시도하면 다음과 같은 오류가 발생합니다(여기서 [site]는 당연히 제 사이트 주소입니다):
```plaintext
[site]:Verify error:Fetching http://[site]/.well-known/acme-challenge/[long alpha challenge string]: Error getting validation data
```
참고로 이 사이트는 모든 사용자 접근에 로그인이 필요하지만, 이전 수년간의 운영 기간 동안 SSL 인증서 갱신에는 문제가 없었습니다.
아무 아이디어가 있으신가요? 정말 감사합니다!
업데이트: wget를 사용하여 검증 테스트를 수행하면 404가 반환됩니다. 그러나 컨테이너 내 Discourse용 nginx에서 이 데이터가 어디에 구성되는지, 그리고 컨테이너 외부로 프록시하는 관련 nginx와 어떤 관계가 있는지 알지 못합니다.
---
### Author:  [@JammyDodger](https://meta.discourse.org/u/JammyDodger)
#### Post date: [12월 24, 2021, 6:31오후 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/2 "2021-12-24T18:31:00Z")
몇 달 전의 것이라면, 이것이 관련이 있을까요?
> **[DST Root CA X3 Expiration (September 2021)](https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/)**
>
> Update Feb 05, 2024 It’s been two years, and the Android compatibility cross-sign mentioned below is close to expiring. See our recent blog post for a detailed explanation of the changes coming over the course of 2024. Update September 30, 2021 As...
---
### Author:  [@L30110](https://meta.discourse.org/u/L30110)
#### Post date: [12월 24, 2021, 6:35오후 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/3 "2021-12-24T18:35:16Z")
안녕하세요. 그 문제는 브라우저에서 인증서가 다른 오류로 거부되는 원인이 되므로, 제 경우처럼 만료 오류와는 관련이 없을 것입니다. Let’s Encrypt이 갑자기 Discourse와 인증에 실패하여 새 인증서를 전달하지 못하는 것으로 보입니다. 감사합니다.
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [12월 24, 2021, 8:18오후 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/4 "2021-12-24T20:18:36Z")
> [@JammyDodger](#):
>
> 몇 달 전의 것이라면, 이건 관련이 있을까요:
첫 만료일이 8월이었다면 관련이 없습니다. 그 이후로 갱신되었어야 합니다.
---
### Author:  [@Benjamin\_D](https://meta.discourse.org/u/Benjamin_D)
#### Post date: [12월 24, 2021, 8:55오후 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/5 "2021-12-24T20:55:53Z")
6월 이후로 업데이트되지 않은 앱의 경우, 다음 문제가 발생했을 수 있습니다: [Letsencrypt certificate failure to renew - #11 by pfaffman](https://meta.discourse.org/t/letsencrypt-certificate-failure-to-renew/204885/11)
> [@L30110](#):
>
> 그러나 컨테이너 내의 Discourse용 nginx에 이 데이터가 어떻게 설정되는지, 그리고 컨테이너 외부로 프록시하는 관련 nginx와 어떻게 관련이 있는지 모릅니다.
찾고 계신 것이 맞는지 확실하지 않지만: [discourse\_docker/templates/web.letsencrypt.ssl.template.yml at main · discourse/discourse\_docker · GitHub](https://github.com/discourse/discourse_docker/blob/main/templates/web.letsencrypt.ssl.template.yml)
---
### Author:  [@L30110](https://meta.discourse.org/u/L30110)
#### Post date: [12월 24, 2021, 9:27오후 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/6 "2021-12-24T21:27:24Z")
안녕하세요. 이 내용들은 제 상황에는 해당되지 않는 것 같습니다. 다른 오류가 아니라 404 오류가 발생하고 있으며, 빌드는 계속 업데이트되어 왔고, GitHub에서 가져온 그 템플릿은 제 설치 환경에 이미 설치되어 있는 버전입니다. 감사합니다!
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [12월 24, 2021, 11:39오후 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/7 "2021-12-24T23:39:35Z")
오렌지 클라우드가 표시된 Cloudflare를 사용 중이신가요, 아니면 다른 리버스 프록시를 사용 중이신가요?
---
### Author:  [@L30110](https://meta.discourse.org/u/L30110)
#### Post date: [12월 24, 2021, 11:51오후 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/8 "2021-12-24T23:51:39Z")
아니요. Ubuntu 18.04에서 기본 Docker 설치로 로컬 호스팅을 사용하고 있습니다.
---
### Author:  [@L30110](https://meta.discourse.org/u/L30110)
#### Post date: [12월 25, 2021, 12:39오전 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/9 "2021-12-25T00:39:26Z")
컨테이너에서 실행되는 cron 작업을 수동으로 실행하여 인증서를 갱신하면, 항상 동일한 오류가 발생합니다. 다음을 가져오려는 시도가 실패합니다:
http://[site]/.well-known/acme-challenge/[challenge-string]
"Error getting validation data."라는 오류가 발생합니다.
---
### Author:  [@Simon\_Manning](https://meta.discourse.org/u/Simon_Manning)
#### Post date: [12월 25, 2021, 12:45오전 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/10 "2021-12-25T00:45:15Z")
해당 프로세스에 익숙하지 않아서, 그 스크립트만 단독으로 실행했을 때 컨테이너가 기대하는 상태와 다른 상태에 있을 수 있는 건가요? 예를 들어, 해당 URL에 대한 접근을 허용하도록 nginx를 준비하는 다른 cron 작업이 먼저 실행되기를 기대하는 것일 수도 있습니다.
재빌드를 시도해 보셨나요? (이 과정에서 새로운 인증서를 발급받으려 합니다.)
로컬에 호스팅되어 있다고 언급하셨는데, 도메인 이름을 사용하여 네트워크 외부에서 해당 인스턴스에 접근할 수 있나요?
---
### Author:  [@L30110](https://meta.discourse.org/u/L30110)
#### Post date: [12월 25, 2021, 12:56오전 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/11 "2021-12-25T00:56:05Z")
안녕하세요, 네, _여러 번_ 재구축했습니다. 변경된 점은 없습니다. 저는 Let’s Encrypt를 Discourse가 아닌 여러 사이트에서 사용하고 있으며, 모두 정상적으로 갱신됩니다. 네, 외부 사이트에서 접근할 수 있으며 wget으로 테스트해 본 결과 404가 반환됩니다. 질문: 이 경우 nginx의 html 트리(즉, .well-known 디렉터리를 포함하거나 포함해야 하는 부분)가 정확히 _어디_에 있나요? 찾지 못했습니다. 감사합니다.
---
### Author:  [@Simon\_Manning](https://meta.discourse.org/u/Simon_Manning)
#### Post date: [12월 25, 2021, 1:30오전 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/12 "2021-12-25T01:30:16Z")
cron 작업을 찾을 수 없었고, `/etc/runit/1.d/letsencrypt`에 runlevel 스크립트만 있었습니다. 해당 스크립트는 다음 내용을 포함하는 설정으로 nginx의 새 인스턴스를 시작하는 것으로 보입니다:
```plaintext
location ~ /.well-known {
root /var/www/discourse/public;
allow all;
}
```
이는 경로가 `/var/www/discourse/public/acme-challenge`가 될 것이라는 것을 의미합니다. 다만, 챌린지 전에 생성되었다가 이후에 삭제될 수도 있습니다.
만약 해당 스크립트를 수동으로 실행해 보셨다면, 먼저 nginx를 중지하셨나요? 스크립트가 시작하려는 인스턴스는 포트 80을 리스닝하려고 할 것이므로, Discourse를 위해 nginx가 이미 실행 중이라면 실패할 것으로 추정됩니다.
---
### Author:  [@L30110](https://meta.discourse.org/u/L30110)
#### Post date: [12월 25, 2021, 1:33오전 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/13 "2021-12-25T01:33:26Z")
문제를 파악한 것 같습니다. 하지만 어떻게 수정해야 할지는 모르겠네요. HTTPS 포트 80으로 포럼에 접근하려는 모든 시도가 (예상대로) HTTPS 443으로 리다이렉트되고 있는 것 같습니다. 맞습니다. 하지만 이는 Let’s Encrypt가 갱신을 위해 인증을 시도할 때, 현재 인증서가 만료되었기 때문에 실패한다는 뜻입니다. wget으로 리다이렉트를 확인할 수 있습니다. 따라서 질문은, Let’s Encrypt가 인증을 완료하고 만료되지 않은 새로운 인증서를 발급받을 수 있도록 리다이렉트를 일시적으로 비활성화하는 방법입니다. 추가적인 복잡성은 해당 리다이렉트가 301 영구 리다이렉트라는 점입니다. 감사합니다.
---
### Author:  [@Simon\_Manning](https://meta.discourse.org/u/Simon_Manning)
#### Post date: [12월 25, 2021, 2:08오전 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/14 "2021-12-25T02:08:02Z")
이 리다이렉트는 `/etc/nginx/conf.d/discourse.conf`에 있으며, nginx가 중지된 후 이전 게시물에서 언급한 설정으로 시작될 경우 사용되지 않습니다.
자동 업그레이드 방식에 대해 잘 모르기 때문에 컨테이너가 실행 중인 상태에서 갱신을 수행하는 적절한 방법이 무엇인지 확신할 수 없습니다. 이론적으로는 컨테이너를 중지했다가 다시 시작하면 갱신이 이루어져야 하지만, 재빌드(rebuild)로 해결되지 않았다고 하셨으므로 이 방법도 작동하지 않을 가능성이 높습니다.
acme.sh에는 `--renew-all`과 같은 옵션이 있지만, 여기에서 올바르게 작동하려면 어떤 추가 옵션이 필요한지 확실하지 않습니다. 다음 명령이 필요한 모든 것이 될 수 있지만, 단정할 수는 없습니다.
```plaintext
LE_WORKING_DIR="/shared/letsencrypt" /root/acme.sh/acme.sh --renew-all
```
---
### Author:  [@L30110](https://meta.discourse.org/u/L30110)
#### Post date: [12월 25, 2021, 2:52오전 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/15 "2021-12-25T02:52:09Z")
사실상 이 방법은 리다이렉트 없이 Let’s Encrypt가 접근할 수 있게 해주지만, apparently 해당 파일이 존재하지 않아 결국 동일한 인증 실패가 발생합니다.
---
### Author:  [@mbronstein](https://meta.discourse.org/u/mbronstein)
#### Post date: [12월 27, 2021, 4:51오후 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/16 "2021-12-27T16:51:17Z")
저도 같은 문제를 겪고 있습니다. 이 문제를 해결하는 명확한 절차를 알아낸 분이 계신가요?
---
### Author:  [@L30110](https://meta.discourse.org/u/L30110)
#### Post date: [12월 27, 2021, 5:06오후 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/17 "2021-12-27T17:06:40Z")
이제 이 방법으로 인증서를 정상적으로 발급받으려 하고 있습니다. curl로 검증 토큰은 제대로 가져오는 것 같지만, acme.sh는 매번 검증 실패를 보고합니다! 그래서 여전히 다운 상태입니다.
“/shared/letsencrypt”/acme.sh --renew-all --force --insecure --home “/shared/letsencrypt” --debug
---
### Author:  [@griffin](https://meta.discourse.org/u/griffin)
#### Post date: [12월 27, 2021, 8:11오후 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/18 "2021-12-27T20:11:41Z")
안녕하세요 @L30110 🙂
저는 [Let’s Encrypt 커뮤니티](https://community.letsencrypt.org/)의 [정기 방문자](https://community.letsencrypt.org/u/griffin) 중 한 명입니다. @JimPas의 요청으로 이 스레드를 확인하러 왔으며, 점심 식사를 마치고 돌아오는 대로 살펴보겠습니다.
---
### Author:  [@griffin](https://meta.discourse.org/u/griffin)
#### Post date: [12월 27, 2021, 10:24오후 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/19 "2021-12-27T22:24:17Z")
> [@L30110](#):
>
> 이 경우 nginx html 트리가 정확히 어디에 위치합니까? `.well-known` 디렉토리를 포함해야 하는(또는 포함할) 부분이 어디인지요? 저는 이를 찾지 못했습니다.
acme.sh와 같은 많은 ACME 클라이언트에서 nginx를 인증 방법으로 지정하면, [http-01 챌린지](https://letsencrypt.org/docs/challenge-types/#http-01-challenge) 파일은 웹루트 디렉토리의 `.well-known/acme-challenge` 디렉토리 구조 내에 직접 생성되는 것이 아니라, nginx 서버 설정의 예외/리다이렉트 기반으로 특정 디렉토리에 생성됩니다. 종종 이 리다이렉트는 챌린지 검증 기간 동안만 일시적으로 존재하며, 챌린지 파일 자체도 마찬가지입니다.
따라서:
> [@Simon\_Manning](#):
>
> ```plaintext
> location ~ /.well-known {
> root /var/www/discourse/public;
> allow all;
> }
>
> ```
>
> 이는 경로가 `/var/www/discourse/public/acme-challenge`가 될 것이라는 것을 의미하는 것 같습니다. 챌린지 전에 생성되고 나중에 삭제될 수도 있습니다.
* * *
> [@Simon\_Manning](#):
>
> 그 스크립트를 수동으로 실행해 보셨다면, nginx를 먼저 중지하셨습니까? 스크립트가 시작하려는 인스턴스는 포트 80에서 리스닝을 시도할 것이므로, Discourse를 위해 nginx가 이미 실행 중이라면 실패할 것으로 추정됩니다.
현명한 고려 사항입니다. 적절하게 작성된 갱신 스크립트라면 nginx를 중지할 필요가 없어야 합니다. 일반적으로 nginx는 챌린지 파일(들)을 서빙하는 데 사용되고, 새로운 인증서가 발급된 후 웹 서버/프록시를 부드럽게 다시 로드하기 위해 `nginx -s reload`와 유사한 명령이 사용됩니다.
* * *
> [@L30110](#):
>
> https 포트 80으로 포럼에 액세스하려는 모든 시도가 (예상대로) https 443으로 리다이렉트되고 있는 것으로 보입니다. 맞습니다. 하지만 이는 갱신을 위해 Let’s Encrypt가 검증을 시도할 때, 현재 인증서가 만료되었기 때문에 실패한다는 것을 의미합니다.
아닙니다. 😉
[Challenge Types - Let's Encrypt](https://letsencrypt.org/docs/challenge-types/#http-01-challenge) 에 따르면:
> HTTP-01 챌린지 구현은 리다이렉트를 따르며, 최대 10단계까지 가능합니다. “http:” 또는 "https:"로의 리다이렉트만 허용하며, 포트는 80 또는 443만 허용합니다. IP 주소로의 리다이렉트는 허용하지 않습니다. HTTPS URL로 리다이렉트될 경우, 인증서를 검증하지 않습니다(이 챌린지는 유효한 인증서를 부트스트랩하기 위한 것이므로, 중간에 자체 서명되거나 만료된 인증서에 karşılaş을 수 있기 때문입니다).
* * *
이러한 문제를 볼 때, 일반적으로 다음 중 하나가 원인이 됩니다:
- 챌린지 파일(들)을 서빙하는 웹 서버/프록시로 트래픽을 허용하지 않는 방화벽
- 챌린지 검증 요청이 Boulder(Let’s Encrypt CA 서버)에서 잘못된 웹 서버나 디렉토리에서 파일(들)을 가져오도록 시도하게 되는, 부적절하게 매핑/구성된 라우터/프록시
- 챌린지 파일을 올바른 위치에서 서빙하는 것을 방해하는 어떤 유형의 재작성/리다이렉트 (예: Apache의 `.htaccess` 파일)
- 부적절한 매핑과 함께 사용된 비표준 포트
- ACME 클라이언트를 실행하는 컨테이너가 웹 서버/프록시(예: nginx)가 서빙하지 않는 위치에 챌린지 파일(들)을 생성하는 경우. Docker가 관여되면 거의 항상 이것이 문제입니다.
---
### Author:  [@L30110](https://meta.discourse.org/u/L30110)
#### Post date: [12월 27, 2021, 11:04오후 UTC](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071/20 "2021-12-27T23:04:59Z")
안녕하세요. 목록에 나열된 항목들 중 몇 가지는 제 상황에 명확히 해당되지 않습니다. 방화벽 문제는 아닙니다. 1) docker discourse 앱 내부에서, 2) docker 컨테이너 외부의 호스트 시스템에서, 3) 관련 시스템에서 wget 또는 curl을 사용하여 수동으로 토큰에 접근할 수 있기 때문입니다.
이러한 수동 접근의 경우, Discourse가 자동으로 https로 리다이렉트할 때 만료된 인증서를 우회하기 위해 --ignore 또는 -k 옵션을 지정한다고 가정하면, 예상된 위치에서 토큰 내용을 정상적으로 받아옵니다.
Discourse가 생성한 nginx 구성의 어떤 부분도 변경하지 않았습니다. 컨테이너 내부든 외부든 마찬가지입니다. nginx의 복사본을 실행하지 않고 있으며, Apache는 로컬 사용만을 위해 완전히 다른 포트에서 실행됩니다. 지난 2년 동안 정기적인 인증서 갱신 외에는 앱 변경 사항 없이 모든 것이 정상적으로 작동해 왔다는 점을 고려하면, 이 시스템은 매우 안정적입니다.
비정상적인 포트는 없습니다.
수동으로 토큰 내용을 가져올 수 있으므로, 잘못된 위치가 문제일 수 있다고 보기는 어렵습니다. 다만 …
테스트를 위해 nginx를 수동으로 중지하지는 않았습니다. 이제 그렇게 해보았지만, 큰 차이는 없었습니다 – acme.sh에서 동일한 오류가 발생했습니다(현재 다시 오류 56입니다). 컨테이너 내부에서 nginx를 중지하면 호스트에서 runsv nginx 인스턴스가 보이지만, 워커나 캐시 프로세스는 없습니다. 컨테이너에서 nginx를 다시 시작하면, 남아 있던 runsv nginx와 함께 워커 및 캐시 프로세스가 호스트에 다시 나타납니다. 컨테이너 내부의 sv start/stop nginx 명령은 해당 작업에 대한 예상된 확인 메시지를 표시합니다.
그러나 위에서 언급된 또 다른 문제가 우려될 수 있습니다. 그리고 지금까지 오랫동안 정상적으로 작동해 왔는데 왜 갑자기 문제가 되는지 이해가 되지 않습니다.
로컬 네트워크 외부에서 포럼에 사용할 때 사용되는 정적 IP 주소는 ISP가 정적 IP를 제공하는 방식의 복잡성으로 인해, 해당 머신이 자신의 서비스로 연결하는 데에는 사용할 수 없습니다. 저는 /etc/hosts 항목을 사용하여 이러한 이름에 대한 로컬 네트워크 IP 주소를 정기적으로 지정해 왔습니다. 따라서 같은 머신에서 curl로 테스트할 때(컨테이너 내부든 외부든 포럼에 대한 /etc/hosts 추가 항목이 모두 존재합니다), DNS를 통해 조회하는 외부 사이트가 사용할 것과 다른(로컬) IP 주소가 테스트에 사용됩니다. 이것이 관련이 있을 수 있는 방법은 있을까요? 감사합니다.
[다음 페이지](https://meta.discourse.org/t/lets-encrypt-cert-renewals-suddenly-failing/213071.md?page=2)