Échec du renouvellement du certificat Discourse

[RBoy]

Continuant la conversation à partir d’ici :

Letsencrypt certificate failure to renew

I think it’s been years since I’ve seen a let’s encrypt certificate fail to renew, but I’ve had three sites in the past week or two that have stale certificates. A rebuild fixes it and I have heretofore failed to look for clues in the logs. Next time I’ll do a bit more to diagnose the problem before fixing it for the site.

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)

[pfaffman (Jay Pfaffman)]

Il y a eu une période pendant laquelle le point de terminaison dont Let’s Encrypt avait besoin était redirigé. C’est corrigé si vous reconstruisez.

[Dannii]

Combien de temps après la mise à jour le certificat doit-il être renouvelé ?

[featheredtoast (Jeff Wong)]

Si ma mémoire est bonne, les certificats sont valides pendant 3 mois et ils tenteront maintenant de renouveler automatiquement avant cette date.

[Dannii]

Oui, je sais comment cela est censé fonctionner.

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é ?

[RBoy]

Pour moi, le certificat a été mis à jour immédiatement après la reconstruction.

[Dannii]

Avez-vous reconstruit via le Web ou via la ligne de commande ?

[Canapin (Coin-coin le Canapin)]

Oui, l’explication était ici :

Let's Encrypt certificate doesn't automatically renew, but rebuilding does trigger the renewal

I recently worked on the le cert renewal. It is the http to https redirect - acme does not handle being told to redirect well at all and by default attempts to connect on the same protocol (http) as it did when it was setup initially Recent updates to the let’s encrypt template should fix these renewals going forward.

[Dannii]

Mon forum a enfin mis à jour son certificat après que j’ai effectué une reconstruction en ligne de commande.

[lessLost (Michael)]

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.

Peut-être que cela a commencé après le commit ae4887a de discourse-docker ?

[pfaffman (Jay Pfaffman)]

Il y a eu une autre erreur sur la route bien connue dont on se souvient récemment.

Quand avez-vous fait une reconstruction pour la dernière fois ?

[giuseppe.lanzi]

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.

[lessLost (Michael)]

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.

[pfaffman (Jay Pfaffman)]

Si vous pensez qu’il s’agit d’un Discourse, vous devriez peut-être répondre sur le commit github ou ouvrir un nouveau rapport important.

[cedric_chin]

@lessLost

Dans mes tests sur une installation nginx standard (1.18.0 mais je pense que c’est la même chose pour 1.26.3), une ligne de configuration nginx return 301 https://thehostname$request_uri; en dehors d’un bloc location écrase complètement tout bloc location précédent, au lieu d’être un attrape-tout. Je crois que /.well-known/ n’est simplement pas servi sur le port 80 à moins que la redirection 301 ne soit spécifiquement pour un autre emplacement tel que / à la fin du bloc server. Pourrait-il s’agir du même problème que ce post stackoverflow ?

Je peux confirmer que le renouvellement letsencrypt échoue. J’utilise une installation Discourse auto-hébergée depuis des années, et très étrangement, le renouvellement a échoué deux fois de suite au cours des deux derniers mois. La deuxième fois, c’était ce matin, et j’ai donc commencé à enquêter.

J’ai identifié les deux commits suivants :

Use Nginx config outlets in templates

Et la ligne pertinente liée :

FEATURE: Move letsencrypt scripts to work on boot (#977)

Il y a deux problèmes, je pense.

Premièrement, return 301 https://${DISCOURSE_HOSTNAME}$request_uri; se transforme en return 301 https://<MON NOM DE SERVEUR> sans $request_uri à la fin. J’ai vérifié sur mon installation auto-hébergée, ainsi que sur l’installation auto-hébergée d’un ami configurée la semaine dernière. Je ne comprends pas comment le modèle Discourse fonctionne, donc je ne sais pas pourquoi il est supprimé.

Deuxièmement, comme l’a mentionné @lessLost, la redirection 301 est en dehors du bloc location. Je crois qu’une redirection au niveau du serveur écrase tous les blocs location. LetsEncrypt utilise http pour les renouvellements. Cependant, toute tentative de curl -I http://VOTRE_DOMAINE/.well-known/acme-challenge/test renverra un 301 vers https, au lieu d’un 404 (ce qui est le comportement attendu ; nous voulons un 404 et non un 301).

J’ai corrigé cela manuellement sur mon installation auto-hébergée, mais je m’attends à ce que toute mise à jour écrase mes modifications. Malheureusement, je ne comprends pas assez les modèles pour soumettre une pull request @pfaffman — sinon je le ferais aussi.

Modifié pour ajouter :

Je crois que c’est une erreur —

Let's Encrypt certificate doesn't automatically renew, but rebuilding does trigger the renewal

I recently worked on the le cert renewal. It is the http to https redirect - acme does not handle being told to redirect well at all and by default attempts to connect on the same protocol (http) as it did when it was setup initially Recent updates to the let’s encrypt template should fix these renewals going forward.

Je suis presque certain que LetsEncrypt utilise http par défaut (pour des raisons évidentes, si le certificat est expiré, il ne peut pas se renouveler !) Mais placer le 301 au niveau du bloc server force toutes les requêtes à être redirigées en 301 vers https, ce qui est incohérent avec cette stratégie de renouvellement.

[pfaffman (Jay Pfaffman)]

Quand avez-vous reconstruit pour la dernière fois ?

[cedric_chin]

Ce matin, environ 10 minutes après mon réveil, j’ai visité mon forum et j’ai réalisé que le certificat avait expiré à nouveau. (Reconstruire était ce qui avait renouvelé la dernière fois qu’il m’a expiré — il y a environ 3 mois ?)

[pfaffman (Jay Pfaffman)]

@cedric_chin

(La reconstruction a été ce qui a renouvelé la dernière fois que cela m’a expiré — il y a environ 3 mois ?)

Je pense qu’ils ont apporté des modifications depuis lors qui ont résolu ce problème, mais comme il faut 3 mois pour le savoir, le jury n’a pas encore statué. Vous pourriez régler un rappel quelques semaines avant l’expiration du certificat actuel.

[cedric_chin]

Ce n’est pas vrai.

1. Les liens que j’ai joints dans le commentaire ci-dessus provenaient d’un git blame. Voici la dernière version du fichier (ligne pertinente liée) : discourse_docker/templates/web.ssl.template.yml at 247c71a1e45d32b0b814a8e9d5fdaa4faaf727b9 · discourse/discourse_docker · GitHub
2. La nouvelle installation du site de mon ami date d’il y a une semaine. La ligne 37 du modèle ci-dessus indique : return 301 https://${DISCOURSE_HOSTNAME}$request_uri; mais dans le conteneur Docker de Discourse, le fichier /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf de son site (et du mien) indique return 301 https://<votre_site_discourse>; Remarquez comment $request_uri est supprimé. Quelque chose le fait disparaître ! (Je ne sais pas quoi).
3. J’ai effectué un renouvellement forcé simulé ce matin dans le cadre de mon enquête. Cela a échoué. J’ai ensuite modifié /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf. Cela a réussi !

C’est en fait acceptable ; je modifierai simplement manuellement 20-redirect-http-to-https.conf chaque fois que je mettrai à jour Discourse. Pour ceux qui tombent sur ce commentaire, la commande à exécuter est :

cat > /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf << 'EOF'
server {
  listen 80;
  listen [::]:80;

  location ~ /.well-known {
    root /var/www/discourse/public;
    allow all;
  }

  location / {
    return 301 https://<VOTRE_ADRESSE_FORUM>$request_uri;
  }
}
EOF

Je ne suis pas entièrement sûr de ce qui cause cet échec, mais je sais que la modification du fichier de configuration ci-dessus le résout. Mais j’ai également modifié les notifications afin que les renouvellements letsencrypt n’échouent plus silencieusement — afin que je puisse avoir un avertissement préalable. Je pensais juste que vous aimeriez le savoir !

[nat (Natalie T)]

Merci pour le signalement, je pense que c’est légitime.

(pour information @featheredtoast)