Lors d’une reconstruction, j’ai vu l’avertissement :
« L’e-mail Let’s Encrypt n’est pas défini »
Mais dans mon fichier app.yml, j’ai déjà cette ligne :
LETSENCRYPT_ACCOUNT_EMAIL: myemail@example.com
Mon certificat est valide et l’émission est ignorée. Le lanceur affiche l’avertissement correct.
Avant de mettre à jour quoi que ce soit, quelqu’un peut-il confirmer :
Est-ce que LETSENCRYPT_ACCOUNT_EMAIL est une variable ancienne/héritée ?
Le nom de variable moderne correct est-il maintenant :
letsencrypt_email:
Dois-je supprimer l’ancienne variable et passer à la nouvelle pour éviter les avertissements et assurer le bon fonctionnement du renouvellement automatique ?
Merci pour les réponses jusqu’à présent — J’ai fait quelques recherches supplémentaires et je voudrais vérifier si j’ai bien compris la situation.
Mon installation a été créée à l’origine avec ./discourse-setup, ce qui a ajouté
LETSENCRYPT_ACCOUNT_EMAIL: myemail@example.com
sous env: dans app.yml.
Let’s Encrypt émet et renouvelle les certificats avec succès depuis lors, et le web.letsencrypt.ssl.template.yml actuel semble toujours utiliser LETSENCRYPT_ACCOUNT_EMAIL comme variable d’environnement sur laquelle il s’appuie. Lors d’une nouvelle installation de test aujourd’hui, j’ai vu la sortie d’amorçage habituelle :
I, [2025-12-07T12:29:22.272059 #1] INFO -- : Replacing # after ssl with if [ -n "$LETSENCRYPT_ACCOUNT_EMAIL" ]; then
if [[ ! "$LETSENCRYPT_ACCOUNT_EMAIL" =~ ([^@]+)@([^\\.]+) ]]; then
echo "LETSENCRYPT_ACCOUNT_EMAIL is not a valid email address"
exit 1
fi
/usr/local/bin/configure-ssl
exec /usr/local/bin/configure-letsencrypt
else
echo "LETSENCRYPT_ACCOUNT_EMAIL ENV not set. Skipping Let's Encrypt setup."
fi
# after ssl in /etc/runit/1.d/install-ssl
ce qui correspond à ce qui se trouve dans le modèle.
Cependant, lorsque j’exécute ./launcher rebuild app, je vois maintenant un avertissement du type « L’e-mail Let’s Encrypt n’est pas défini ». D’après la lecture du lanceur et de la documentation connexe, cela semble provenir d’une vérification de configuration plus récente qui recherche une clé letsencrypt_email dans la configuration fusionnée, plutôt que l’ancienne variable d’environnement LETSENCRYPT_ACCOUNT_EMAIL.
Je pense donc que la situation actuelle est la suivante :
Le modèle Docker Let’s Encrypt utilise toujours LETSENCRYPT_ACCOUNT_EMAIL comme variable d’environnement qui pilote acme.sh et le renouvellement.
Certaines vérifications plus récentes (par exemple, celle qui affiche « L’e-mail Let’s Encrypt n’est pas défini ») ne recherchent que letsencrypt_email dans la configuration.
Cela expliquerait pourquoi l’émission/le renouvellement du certificat fonctionne bien alors que la reconstruction affiche toujours un avertissement.
Quelques éclaircissements que j’aimerais obtenir de l’équipe :
Pour les installations standard ./discourse-setup, LETSENCRYPT_ACCOUNT_EMAIL est-il toujours le nom de variable prévu dans app.yml, ou devrions-nous maintenant utiliser letsencrypt_email à la place ?
LETSENCRYPT_ACCOUNT_EMAIL est-il considéré comme obsolète mais pris en charge à ce stade, ou y a-t-il un plan pour migrer les modèles vers une nouvelle clé ?
Pour les installations existantes qui utilisent actuellement LETSENCRYPT_ACCOUNT_EMAIL et dont les renouvellements fonctionnent, quelle est l’approche recommandée :
(a) ne rien faire et ignorer en toute sécurité l’avertissement du lanceur, ou
(b) ajouter une entrée letsencrypt_email: à env: (avec la même adresse) uniquement pour satisfaire la vérification la plus récente ?
J’essaie principalement de maintenir la configuration alignée sur ce qui est la « direction officielle », et d’éviter les surprises si l’intégration Let’s Encrypt est refactorisée à l’avenir.
Merci encore pour vos conseils, et pour avoir confirmé ce qui est attendu ici.