Bei einer Installation oder einem Rebuild von Discourse kann ein gültiges Let’s Encrypt-Zertifikat mit folgender Fehlermeldung abgelehnt werden:
C=US, O=Let's Encrypt, CN=YR2
error 2 at 1 depth lookup: unable to get issuer certificate
error fullchain.cer: verification failed
Ich konnte dies unmittelbar nach einer erfolgreichen RSA-Ausstellung reproduzieren. Die fehlgeschlagene Prüfung löst eine unnötige --force-Anfrage aus, was zu HTTP 429 / rateLimited / “too many certificates” führen kann. In meiner Installation wurde die ECDSA-Ausstellung daraufhin blockiert und HTTPS startete nicht.
Bei den betroffenen Ketten kann jeder Rebuild oder Neustart des Containers eine unnötige erzwungene Neuausstellung von RSA- und ECDSA-Zertifikaten auslösen, selbst wenn diese noch gültig sind. Erfolgreiche Neuausstellungen verbrauchen das Let’s Encrypt-Kontingent, sodass wiederholte Rebuilds oder Neustarts schnell das Ratenlimit erreichen können.
Dies kann unbemerkt bleiben, solange HTTPS mit bereits installierten Zertifikaten weiter funktioniert. Das Löschen und Neuinstallieren einer Instanz mit demselben Hostnamen setzt dieses Kontingent nicht zurück. Wenn auf der neuen Installation die erforderlichen Zertifikate fehlen, kann die ratiogegrenzte Ausstellung verhindern, dass HTTPS startet.
Lösung
Ersetzen Sie in templates/web.letsencrypt.ssl.template.yml innerhalb von cert_exists() Folgendes:
- openssl verify -CAfile <(openssl x509 -in ca.cer) fullchain.cer
+ openssl verify -untrusted ca.cer fullchain.cer
Den Rest der Funktion unverändert lassen. Die korrigierte Vorlage muss in den nächsten Container-Rebuild einbezogen werden, um /usr/local/bin/letsencrypt zu aktualisieren.
Falls Sie bereits ratiogegrenzt sind, setzt der Patch das Kontingent nicht zurück. Wenden Sie die Lösung an und beachten Sie die retry after-Zeit, bevor Sie weitere Ausstellungsvorgänge versuchen.
Bestätigung des Kettenverifizierungsproblems
Vergleichen Sie im betroffenen Zertifikatsverzeichnis innerhalb des Containers (/shared/letsencrypt/<hostname> oder <hostname>_ecc) Folgendes:
openssl verify -CAfile <(openssl x509 -in ca.cer) fullchain.cer
openssl verify -untrusted ca.cer fullchain.cer
Im reproduzierten Fall schlägt der erste Befehl mit Fehler 2 fehl; der zweite liefert:
fullchain.cer: OK
Ursache und Validierung
openssl x509 -in ca.cer liest nur das erste Zertifikat aus dem Ausstellerbündel. Bei der beobachteten YR2-Kette wird dadurch das cross-signierte Root YR verworfen, das benötigt wird, um ISRG Root X1 zu erreichen.
-untrusted ca.cer stellt das vollständige Ausstellerbündel bereit, während die Vertrauensanker im System-Speicher verbleiben. Dies bewahrt die Absicht des Fixes aus 2021 (#576).
Ich habe die tatsächlichen RSA- und ECDSA-Ketten innerhalb des Containers verifiziert. Ein vollständiger Rebuild mit dem Patch wiederverwendete beide vorhandenen Zertifikate: zwei Skip-Meldungen, beide Ketten installiert und nginx -t bestand.