Hosted-by-discourse utilise des certificats SSL expirés alors que la page de statut est verte

Soutien
1

Cela fait planter notre site pour le moment ; tous les posts ici semblent concerner des sites auto-hébergés.

❯ 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
---
Chaîne de certificats
 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
---

Les points de terminaison de l’API nous renvoient une erreur de certificat expiré, vérifiée via Postman.

2

@équipe, veuillez aider ici.

3

Hmm. Cela semble étrange.

4

Cela ressemble bien à un problème côté vous (c’est-à-dire du côté de votre site web).
Le certificat fourni par le serveur est valide et accepté par presque tous les navigateurs. Le problème vient du fait que de nombreux serveurs plus anciens ne possèdent pas le certificat racine (relativement) récent dans leur magasin de confiance, ce qui provoque actuellement de nombreuses erreurs dans les processus automatisés.

Je ne connais pas votre site exact, alors j’ai pris un site arbitraire hosted-by-discourse.com et je l’ai soumis au Qualys SSL Server Test.

image
image854×760 37.7 KB

Vous pouvez constater que la racine du deuxième chemin de certification est effectivement expirée, mais cela est compensé par la présence du certificat ISRG Root X1 dans le magasin de confiance (c’est-à-dire inclus dans votre navigateur et/ou système d’exploitation) pour le premier chemin de certification.

Les serveurs ne mettent généralement pas à jour leur magasin de confiance fréquemment, il est donc probable que le vôtre ne contienne pas le certificat ISRG Root X1. (C’est ce qui s’est produit également avec l’image Docker du récepteur de courriel).

Vous pouvez trouver un bundle actuel, par exemple sur https://curl.se/ca/cacert.pem. Sur CentOS, ce fichier doit être placé dans /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem. Sur Ubuntu, vous pouvez utiliser la commande update-ca-certificates, qui met à jour /etc/ssl/certs/ca-certificates.crt.

En alternative, vous pouvez temporairement désactiver la vérification du certificat SSL dans le code de votre serveur.

5

J’ai publié la sortie d’openssl pour prouver que cela n’a aucun lien avec notre site web, d’autant plus que Postman est exécuté depuis une machine Windows locale.

Édit : Je ne connais pas aussi bien les différents niveaux de magasins de confiance, je vais m’y pencher davantage, cela se produit simplement sur chaque machine que nous essayons.

6

Cela ne plante pas lorsque vous utilisez un vrai navigateur, n’est-ce pas ?

EDIT : De plus en plus de personnes rencontrent des problèmes avec Postman, donc je suppose que ce n’est pas un test valide… :thinking:

7

Voici la réponse que j’ai reçue de notre responsable DevOps.

Le problème est qu’il existe deux copies de ISRG Root X1 : l’une a été émise par DST Root CA X3 il y a longtemps, et la plus récente a été auto-signée par l’ISRG (le groupe qui gère Let’s Encrypt, entre autres). Cette autorité de certification racine auto-signée est désormais acceptée comme une racine de confiance sur la plupart des systèmes.

Il s’agit du même certificat de signature, vous pouvez donc valider n’importe quoi affirmant être émis par « ISRG Root X1 » avec l’une ou l’autre version. Cependant, celle qui a été signée par DST n’est plus valide en tant que chemin de certification, car le certificat DST qui l’a signée est maintenant expiré.

Si le serveur faisait ce qu’il faut et fournissait la nouvelle version auto-signée de ISRG Root X1, le client comparerait celle fournie avec son propre magasin de confiance, vérifierait qu’il s’agit du même certificat et tout irait bien. Mais au lieu de cela, il voit le certificat fourni, se dit : « D’accord, je dois le valider par rapport à DST Root CA X3 que j’ai en stock… oh non, elle est expirée », et échoue dans la vérification.

8

Fournir un certificat dans la chaîne de certificats qui est censé se trouver dans le magasin de racines de confiance des CA, c’est loin d’être « faire la bonne chose ».

Examinons la chaîne de certificats du site letsencrypt.org lui-même : SSL Server Test: letsencrypt.org (Powered by Qualys SSL Labs)

Tiens, regardez. Ils font la même chose, la chaîne de certificats est identique (sauf pour le certificat du serveur, bien sûr).

image
image812×744 33.1 KB

Donc, soit votre responsable DevOps se trompe, soit CDCK, LetsEncrypt et Qualys se trompent tous.
Dites-lui de mettre à jour le magasin de racines de confiance des CA. Cela résoudra le problème. Croyez-moi.

9

Bonjour @bpaterson2000, désolé d’apprendre que vous rencontrez des problèmes de connexion à notre service hébergé. Comme l’a mentionné @RGJ, le problème ne vient pas de Discourse ; il doit être résolu côté client. (Nos serveurs ne « fournissent » pas le certificat racine, celui-ci est géré par votre client.)

Vous trouverez plus de détails sur ce changement sur le site de Let’s Encrypt :

10

Merci pour ces informations. Il s’agit d’un problème inattendu pour nous, car les erreurs semblaient provenir du serveur hébergé.

Nous utilisons Heroku, qui regroupe les éléments dont vous parlez via Node/packages, apparemment. Il semble que la mise à jour de Node ait été la clé pour réussir à reconnecter l’API REST de Discourse.

Merci pour votre aide.