La toute première fois, j’ai reçu un rappel de Redsift indiquant que mes certificats allaient expirer dans une semaine. Habituellement, Discourse renouvelle les certificats bien à l’avance. Cette fois, ce n’est pas le cas. Avant de commencer une reconstruction (qui est censée résoudre le problème), @Falco, y a-t-il quelque chose que vous souhaitez que je vérifie et que je publie ici pour aider à trouver la cause de l’échec du renouvellement des certificats ?
Le certificat racine est ISRGX1 et voici les informations sur le certificat expirant :
Nom commun (CN)
E6
Organisation (O)
Let’s Encrypt
Unité d’organisation (OU)
Délivré le
mercredi 16 juillet 2025 à 19:36:45
Expire le
mardi 14 octobre 2025 à 19:36:44
La version actuelle est 3.6.0.beta1-dev (7ee52c8f85)
Mais cela fait plus d’un jour que j’ai mis à jour le logiciel du forum et le certificat ne semble pas avoir été mis à jour encore. Il lui reste 5 jours avant d’expirer, il faut donc vraiment le renouveler bientôt.
Je suis sur la branche stable de Discourse si cela fait une différence. Est-il possible que le correctif du point de terminaison n’ait pas été rétroporté ?
Nous avons eu la même expérience de SSL qui ne se renouvelle pas.
Ce serait formidable si quelqu’un pouvait vérifier que web.ssl.template se comporte correctement sur discourse-docker, il m’a semblé que le port 80 ne servait en fait aucune URL /.well-known/ utilisée par Let’s Encrypt, toutes les URL redirigeaient vers SSL, y compris les fichiers de test que j’ai placés manuellement dans /var/www/discourse/public/.well-known/. J’ai dû modifier /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf directement à l’intérieur du conteneur de l’application.
Pareil ici. Je n’ai pas reçu d’avertissement concernant l’expiration du certificat. Entrer sur le serveur et lancer une reconstruction /var/discourse % ./launcher rebuild a fait l’affaire.
Dans mes tests sur une installation nginx vanilla (1.18.0 mais je pense que c’est pareil pour 1.26.3), une ligne de configuration nginx return 301 https://thehostname$request_uri; en dehors d’un bloc location remplace complètement tout bloc location antérieur, au lieu d’agir comme un attrape-tout. Je pense que /.well-known/ n’est tout simplement pas servi sur le port 80, à moins que la redirection 301 ne soit spécifiquement pour un autre bloc location tel que / à la fin du bloc server. Cela pourrait être le même problème que ce post stackoverflow ?
Je suis content que le rebuild fonctionne, mais comme le certificat avait déjà été renouvelé pour moi, je n’ai pas pu confirmer qu’un rebuild permettrait aux serveurs de validation Let’s Encrypt d’y accéder si un certificat avait expiré. Peut-être qu’un rebuild déclenche le renouvellement du certificat avant que cette ligne de modèle ne soit en place ou similaire, plutôt que de corriger les modèles, mais je ne peux pas confirmer si c’est la raison pour laquelle le rebuild permet au renouvellement de fonctionner.