Hosted-by-discourse está usando certificados SSL expirados, mas a página de status está verde

Suporte
1

Isso está derrubando nosso site no momento; parece que todas as postagens aqui tratam de sites auto-hospedados.

❯ 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
---

Os endpoints da API estão retornando um erro de certificado expirado para nós, verificado através do Postman.

2

@equipe, por favor, ajudem aqui.

3

Hmm. Isso parece estranho.

4

Isso realmente parece ser um problema do seu lado (ou seja, do lado do seu site).
O certificado fornecido pelo servidor está correto e é aceito pela maioria dos navegadores. O problema é que muitos servidores mais antigos não possuem o certificado raiz (relativamente) novo em seu repositório de confiança, então muitas automações estão gerando erros no momento.

Como não conheço seu site exato, peguei um site arbitrário hosted-by-discourse.com e o submeti ao Qualys SSL Server Test.

image
image854×760 37.7 KB

Como você pode ver, a raiz do segundo caminho de certificação está, de fato, expirada, mas isso é mitigado pelo fato de o certificado ISRG Root X1 estar presente no repositório de confiança (ou seja, incluído no seu navegador e/ou sistema operacional) para o primeiro caminho de certificação.

Servidores geralmente não atualizam seu repositório de confiança com frequência, então é provável que o seu servidor não tenha o certificado ISRG Root X1 em seu repositório de confiança. (O mesmo ocorreu com a imagem Docker de recebimento de e-mail).

Você pode encontrar um pacote atualizado, por exemplo, em https://curl.se/ca/cacert.pem. No CentOS, esse arquivo deve ser colocado em /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem. No Ubuntu, você pode usar o comando update-ca-certificates, que atualiza /etc/ssl/certs/ca-certificates.crt.

Como alternativa, você pode desabilitar temporariamente a verificação de certificado SSL no código do seu servidor.

5

Publiquei a saída do openssl para provar que não tem nada a ver com nosso site, além disso, o Postman é executado em uma máquina Windows local.

Edição: não tenho tanto conhecimento sobre os diferentes níveis de repositórios de confiança, vou pesquisar mais sobre isso. O problema ocorre em todas as máquinas que tentamos.

6

Ele não está falhando quando você usa um navegador real, correto?

EDIT: mais pessoas com problemas no Postman, então acho que isso não é um teste válido… :thinking:

7

esta é uma resposta que recebi do nosso especialista em DevOps.

O problema é que existem duas cópias do ISRG Root X1: uma delas foi emitida pela DST Root CA X3 há muito tempo, e a mais recente foi autoassinada pela ISRG (o grupo que governa o Let’s Encrypt, entre outras coisas). Essa autoridade certificadora raiz autoassinada agora é aceita como uma RAiz Confiável na maioria dos sistemas.

Trata-se do mesmo certificado de assinatura, então é possível validar qualquer coisa que afirme ter sido emitida pelo ‘ISRG Root X1’ contra qualquer uma das versões. No entanto, a versão assinada pela DST não é mais válida como um caminho de certificação, pois o certificado DST que a assinou expirou.

Se o servidor estivesse agindo corretamente e fornecendo o ISRG Root X1 mais recente (autoassinado), o cliente compararia o fornecido com o seu próprio repositório de confiança, verificaria que se trata do mesmo certificado e tudo estaria bem. Mas, em vez disso, ele vê o certificado fornecido, pensa: “Ok, preciso validar isso contra o DST Root CA X3 que tenho registrado…ops, ele expirou” e falha na verificação.

8

Fornecer um certificado na cadeia de certificados que se espera estar no armazenamento de CA raiz confiável está muito longe de “fazer a coisa certa”.

Vamos analisar a cadeia de certificados do próprio letsencrypt.org: SSL Server Test: letsencrypt.org (Powered by Qualys SSL Labs)

Ei, olhem só. Eles estão fazendo o mesmo; a cadeia de certificados é idêntica (exceto, claro, pelo certificado do servidor).

image
image812×744 33.1 KB

Então, ou seu especialista em DevOps está errado, ou CDCK, LetsEncrypt e Qualys estão errados.
Peça a ele para atualizar o armazenamento de CA raiz. Isso resolverá o problema. Acredite em mim.

9

Olá @bpaterson2000, lamentamos saber que você está enfrentando problemas ao se conectar ao nosso serviço hospedado. Como mencionado pelo @RGJ, isso não é um problema do lado do Discourse — precisa ser corrigido no seu cliente. (Nossos servidores não “fornecem” o certificado raiz; eles são gerenciados pelo seu cliente.)

Você pode encontrar mais detalhes sobre a mudança aqui, no site da Let’s Encrypt:

10

Obrigado pela informação. Esse foi um problema inesperado para nós, já que os erros aparentemente vinham do servidor hospedado.

Usamos o Heroku, que agrupa os recursos mencionados por meio do node/packages, e parece que atualizar o node foi a chave para conseguir conectar com sucesso novamente à API REST do Discourse.

Obrigado pela sua ajuda.