Une installation ou une reconstruction de Discourse peut rejeter un certificat Let’s Encrypt valide avec l’erreur suivante :
C=US, O=Let's Encrypt, CN=YR2
error 2 at 1 depth lookup: unable to get issuer certificate
error fullchain.cer: verification failed
J’ai reproduit ce problème immédiatement après une émission RSA réussie. L’échec de la vérification déclenche une requête --force inutile, ce qui peut entraîner des erreurs HTTP 429 / rateLimited / « too many certificates ». Dans mon installation, l’émission ECDSA a ensuite été bloquée et HTTPS n’a pas démarré.
Avec les chaînes affectées, chaque reconstruction ou redémarrage du conteneur peut déclencher une réémission forcée inutile des certificats RSA et ECDSA, même s’ils sont encore valides. Les réémissions réussies consomment le quota de Let’s Encrypt, de sorte que des reconstructions ou redémarrages répétés peuvent atteindre rapidement la limite de débit.
Ce problème peut passer inaperçu tant que HTTPS continue de fonctionner avec les certificats déjà installés. La suppression et la réinstallation d’une instance avec le même nom d’hôte ne réinitialisent pas ce quota. Si les certificats requis sont manquants sur la nouvelle installation, une émission limitée par le débit peut empêcher le démarrage de HTTPS.
Correctif
Dans templates/web.letsencrypt.ssl.template.yml, à l’intérieur de cert_exists(), remplacez :
- openssl verify -CAfile <(openssl x509 -in ca.cer) fullchain.cer
+ openssl verify -untrusted ca.cer fullchain.cer
Gardez le reste de la fonction inchangé. Le modèle corrigé doit être inclus dans la prochaine reconstruction du conteneur pour mettre à jour /usr/local/bin/letsencrypt.
Si vous êtes déjà soumis à une limitation de débit, le correctif ne réinitialise pas le quota. Appliquez le correctif et respectez le délai indiqué par retry after avant de tenter toute nouvelle émission.
Confirmer le problème de vérification de la chaîne
Depuis le répertoire du certificat affecté à l’intérieur du conteneur (/shared/letsencrypt/<hostname>, ou <hostname>_ecc), comparez :
openssl verify -CAfile <(openssl x509 -in ca.cer) fullchain.cer
openssl verify -untrusted ca.cer fullchain.cer
Dans le cas reproduit, la première commande échoue avec l’erreur 2 ; la seconde renvoie :
fullchain.cer: OK
Cause et validation
openssl x509 -in ca.cer ne lit que le premier certificat du bundle de l’émetteur. Sur la chaîne YR2 observée, il supprime le Root YR contresigné nécessaire pour atteindre ISRG Root X1.
-untrusted ca.cer fournit le bundle complet de l’émetteur tout en conservant les ancres de confiance dans le magasin système, préservant ainsi l’intention du correctif de 2021 (#576).
J’ai vérifié les chaînes RSA et ECDSA réelles à l’intérieur du conteneur. Une reconstruction complète avec le correctif a réutilisé les deux certificats existants : deux messages Skip, les deux chaînes installées, et nginx -t a réussi.