Hosted-by-discourse는 만료된 SSL 인증서를 사용 중인데 상태 페이지는 녹색으로 표시됨

제품 지원
1

현재 이 문제로 인해 저희 사이트가 마비되어 있습니다. 여기의 모든 게시글이 자체 호스팅 사이트에 관한 것인 것 같습니다.

❯ openssl s_client -connect (removed).com:443 -servername (removed).com
CONNECTED(00000005)
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
---
Certificate chain
 0 s:/CN=(removed).com
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

API 엔드포인트에서 만료된 인증서 오류가 반환되고 있으며, Postman을 통해 확인했습니다.

2

@팀 여기 좀 도와주세요

3

음. 이건 좀 이상하네

4

이 문제는 귀하의 측(즉, 귀하의 웹사이트 측)에서 발생한 것으로 보입니다.
서버가 제공하는 인증서는 정상적이며 거의 모든 브라우저에서 받아들여집니다. 문제는 많은 구형 서버에 (상대적으로) 새로운 루트 인증서가 신뢰 저장소(trust store)에 포함되어 있지 않아, 현재 많은 자동화 작업에서 오류가 발생하고 있다는 점입니다.

저는 귀하의 정확한 사이트를 알지 못하므로 임의로 hosted-by-discourse.com 사이트를 하나 선택하여 Qualys SSL Server Test를 실행해 보았습니다.

image
image854×760 37.7 KB

두 번째 인증 경로(certification path)의 루트가 실제로 만료되었음을 확인할 수 있지만, 첫 번째 인증 경로는 ISRG Root X1 인증서가 신뢰 저장소(즉, 브라우저 및/또는 운영 체제에 포함됨)에 포함되어 있어 이 문제가 완화됩니다.

서버는 일반적으로 신뢰 저장소를 자주 업데이트하지 않으므로, 귀하의 서버에는 ISRG Root X1 인증서가 신뢰 저장소에 없을 가능성이 높습니다. (메일 수신기 Docker 이미지에서도 동일한 일이 발생했습니다.)

최신 번들을 https://curl.se/ca/cacert.pem 등에서 찾을 수 있습니다. CentOS의 경우 해당 파일은 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem에 위치합니다. Ubuntu에서는 /etc/ssl/certs/ca-certificates.crt를 업데이트하는 update-ca-certificates 명령을 사용할 수 있습니다.

대안으로, 서버 코드에서 SSL 인증서 검증을 일시적으로 비활성화할 수도 있습니다.

5

openssl의 출력을 게시하여 이것이 우리 웹사이트와 무관함을 증명했습니다. 또한 Postman은 로컬 Windows 머신에서 실행되고 있습니다.

수정: 저는 신뢰 저장소(trust stores)의 다양한 수준에 대해 그렇게 잘 알고 있지 않습니다. 더 조사해 보겠습니다. 우리가 시도하는 모든 머신에서 이 문제가 발생하기 때문입니다.

6

실제 브라우저를 사용할 때는 실패하지 않는 것이 맞나요?

수정: Postman에서 문제가 발생하는 사람이 더 많아지는 것 같으니, 그건 유효한 테스트가 아닌 것 같습니다… :thinking:

7

다음은 우리 DevOps 담당자로부터 받은 답변입니다.

문제는 ISRG Root X1이 두 개라는 것입니다. 그중 하나는 오래전에 DST Root CA X3에 의해 발급되었고, 더 새로운 하나는 ISRG(Let’s Encrypt 등을 관리하는 단체)가 자체 서명한 것입니다. 그리고 이 자체 서명된 루트 CA는 현재 대부분의 시스템에서 신뢰할 수 있는 루트 CA로 인정받고 있습니다.

두 인증서는 동일한 서명 인증서이므로, ‘ISRG Root X1’에 의해 발급되었다고 주장하는任何东西를 두 버전 중 어느 것에 대해서도 검증할 수 있습니다. 하지만 DST에 의해 서명된 버전은 그 DST 인증서가 현재 만료되었기 때문에 더 이상 유효한 인증 경로로 사용될 수 없습니다.

서버가 올바르게 동작했다면 자체 서명된 새로운 ISRG Root X1을 제공했을 것이고, 클라이언트는 제공된 인증서를 자신의 신뢰 저장소와 비교하여 동일한 인증서임을 확인한 후 정상적으로 처리했을 것입니다. 하지만 실제로는 클라이언트가 제공된 인증서를 확인한 뒤, “아, 이건 내 기록에 있는 DST Root CA X3에 대해 검증해야 하는데… 아, 만료되었네”라고 판단하여 검증에 실패하게 됩니다.

8

신뢰할 수 있는 루트 CA 스토어에 포함되어야 하는 인증서 체인의 인증서를 제공하는 것은 "올바르게 작동하는 것"이 아닙니다.

letsencrypt.org 자체의 인증서 체인을 살펴보겠습니다: SSL Server Test: letsencrypt.org (Powered by Qualys SSL Labs)

보세요. 동일한 인증서 체인을 사용하고 있습니다(물론 서버 인증서는 제외).

image
image812×744 33.1 KB

따라서 DevOps 담당자가 틀렸거나, CDCK 그리고 LetsEncrypt 그리고 Qualys가 틀린 것입니다.
그에게 루트 CA 스토어를 업데이트하라고 하세요. 그러면 문제가 해결됩니다. 믿으세요.

9

Hi @bpaterson2000 - 연결에 문제가 있다는 소식에 안타깝습니다. @RGJ님이 언급했듯이, 이는 Discourse 측의 문제가 아닙니다. 클라이언트 측에서 수정해야 합니다. (우리의 서버는 루트 인증서를 '제공’하지 않으며, 인증서는 클라이언트에서 관리됩니다)

변경 사항에 대한 자세한 내용은 Let’s Encrypt에서 확인할 수 있습니다:

10

정보 감사합니다. 에러가 호스팅 서버에서 반환되는 것으로 보였기 때문에 우리에게는 예상치 못한 문제였습니다.

우리는 Heroku를 사용하는데, 말씀하신 내용들이 node/packages를 통해 번들링되는 것 같습니다. node를 업데이트하는 것이 discourse REST API에 다시 성공적으로 연결하는 데 핵심이었던 것 같습니다.

도움 주셔서 감사합니다.