Ich kann bestätigen, dass die Let’s Encrypt-Erneuerung fehlschlägt. Ich betreibe seit Jahren eine selbst gehostete Discourse-Installation, und sehr seltsamerweise ist die Erneuerung bei mir in den letzten zwei Monaten zweimal hintereinander fehlgeschlagen. Das zweite Mal war heute Morgen, und deshalb habe ich angefangen zu recherchieren.
Ich habe es auf die folgenden zwei Commits zurückgeführt:
Und die relevante verlinkte Zeile:
Ich denke, es gibt zwei Probleme.
Erstens wird return 301 https://${DISCOURSE_HOSTNAME}$request_uri; zu return 301 https://<MEIN SERVERNAME> ohne ein $request_uri am Ende. Ich habe dies auf meiner selbst gehosteten Installation und auch auf der eines Freundes, die in der letzten Woche eingerichtet wurde, überprüft. Ich verstehe nicht, wie die Discourse-Vorlage funktioniert, daher weiß ich nicht, warum es weggelassen wird.
Zweitens, wie @lessLost erwähnt hat, befindet sich der 301-Redirect außerhalb des location-Blocks. Ich glaube, ein Redirect auf Server-Ebene überschreibt alle location-Blöcke. LetsEncrypt verwendet HTTP für Erneuerungen. Jeder Versuch, curl -I http://DEINE_DOMAIN/.well-known/acme-challenge/test auszuführen, gibt jedoch einen 301 zu HTTPS zurück, anstatt eines 404 (was das erwartete Verhalten ist; wir wollen einen 404 und keinen 301).
Ich habe dies manuell auf meiner selbst gehosteten Installation behoben, aber ich erwarte, dass jedes Update meine Änderungen überschreibt. Leider verstehe ich die Vorlagen nicht gut genug, um einen Pull-Request einzureichen, @pfaffman – sonst würde ich das auch tun.
Bearbeitet, um hinzuzufügen:
Ich glaube, das ist falsch –
Ich bin mir ziemlich sicher, dass LetsEncrypt standardmäßig HTTP verwendet (aus offensichtlichen Gründen, wenn das Zertifikat abgelaufen ist, kann es nicht erneuert werden!). Aber das Platzieren des 301 auf Serverblock-Ebene erzwingt, dass alle Anfragen zu HTTPS umgeleitet werden, was nicht mit dieser Erneuerungsstrategie übereinstimmt.