Discourse 설치 또는 재구축 시 유효한 Let’s Encrypt 인증서가 다음과 같은 오류로 거부될 수 있습니다:
C=US, O=Let's Encrypt, CN=YR2
error 2 at 1 depth lookup: unable to get issuer certificate
error fullchain.cer: verification failed
저는 RSA 발급이 성공한 직후 이를 즉시 재현했습니다. 실패한 확인 작업은 불필요한 --force 요청을 트리거하여 HTTP 429 / rateLimited / “too many certificates” 오류로 이어질 수 있습니다. 제 설치 환경에서는 이후 ECDSA 발급이 차단되어 HTTPS가 시작되지 않았습니다.
영향을 받는 체인에서, 인증서가 여전히 유효한 경우에도 각 재구축 또는 컨테이너 재시작 시 RSA 및 ECDSA 인증서의 불필요한 강제 재발급이 트리거될 수 있습니다. 성공적인 재발급은 Let’s Encrypt 할당량을 소모하므로, 반복적인 재구축 또는 재시작은 속도 제한에 빠르게 도달할 수 있습니다.
이미 설치된 인증서로 HTTPS가 계속 작동하는 동안에는 이를 인지하지 못할 수 있습니다. 동일한 호스트네임으로 인스턴스를 삭제하고 다시 설치해도 해당 할당량이 초기화되지 않습니다. 새 설치에 필요한 인증서가 누락된 경우, 속도 제한된 발급으로 인해 HTTPS 시작이 방지될 수 있습니다.
수정 방법
templates/web.letsencrypt.ssl.template.yml 파일의 cert_exists() 함수 내에서 다음을 교체하십시오:
- openssl verify -CAfile <(openssl x509 -in ca.cer) fullchain.cer
+ openssl verify -untrusted ca.cer fullchain.cer
함수의 나머지 부분은 변경하지 마십시오. 수정된 템플릿은 /usr/local/bin/letsencrypt를 업데이트하기 위해 다음 컨테이너 재구축에 포함되어야 합니다.
이미 속도 제한에 걸린 경우, 패치는 할당량을 초기화하지 않습니다. 수정 사항을 적용하고 추가 발급을 시도하기 전에 retry after 시간을 준수하십시오.
체인 검증 문제 확인
컨테이너 내부의 영향받은 인증서 디렉터리(/shared/letsencrypt/<hostname> 또는 <hostname>_ecc)에서 다음을 비교하십시오:
openssl verify -CAfile <(openssl x509 -in ca.cer) fullchain.cer
openssl verify -untrusted ca.cer fullchain.cer
재현된 경우, 첫 번째 명령은 오류 2로 실패하고 두 번째 명령은 다음을 반환합니다:
fullchain.cer: OK
원인 및 검증
openssl x509 -in ca.cer는 발급자 번들에서 첫 번째 인증서만 읽습니다. 관찰된 YR2 체인의 경우, ISRG Root X1에 도달하는 데 필요한 크로스 서명된 Root YR이 누락됩니다.
-untrusted ca.cer는 신뢰 앵커를 시스템 저장소에 유지하면서 전체 발급자 번들을 제공하여 2021년 수정 사항(#576)의 의도를 보존합니다.
저는 컨테이너 내부에서 실제 RSA 및 ECDSA 체인을 검증했습니다. 패치를 적용한 전체 재구축 시 기존 인증서 두 개가 모두 재사용되었습니다: 두 개의 Skip 메시지가 표시되고, 두 체인이 모두 설치되었으며, nginx -t가 통과했습니다.