Discourse-Zertifikat abgelaufen

Das ist nicht wahr.

  1. Die Links, die ich im obigen Kommentar angehängt habe, stammten von einem git blame. Hier ist die neueste Version der Datei (relevante Zeile verlinkt): discourse_docker/templates/web.ssl.template.yml at 247c71a1e45d32b0b814a8e9d5fdaa4faaf727b9 · discourse/discourse_docker · GitHub
  2. Die neue Site-Installation meines Freundes war von vor einer Woche. Zeile 37 der obigen Vorlage lautet: return 301 https://${DISCOURSE_HOSTNAME}$request_uri;, aber im Discourse Docker Container liest sowohl ihre (als auch meine) /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf return 301 https://<your_discourse_site>;. Beachten Sie, dass $request_uri entfernt wird. Etwas bewirkt, dass dies verschwindet! (Ich weiß nicht was).
  3. Ich habe heute Morgen eine simulierte erzwungene Erneuerung als Teil meiner Untersuchung durchgeführt. Sie ist fehlgeschlagen. Ich habe dann /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf geändert. Sie war erfolgreich!

Das ist eigentlich in Ordnung; ich werde 20-redirect-http-to-https.conf einfach jedes Mal manuell bearbeiten, wenn ich Discourse aktualisiere. Für diejenigen, die auf diesen Kommentar stoßen, lautet der auszuführende Befehl:

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://<DEINE_FORUM_ADRESSE>$request_uri;
  }
}
EOF

Ich bin mir nicht ganz sicher, was dieses Scheitern verursacht, aber ich weiß, dass die Änderung der obigen Konfiguration es behebt. Aber ich habe auch Benachrichtigungen so modifiziert, dass Let’s Encrypt-Erneuerungen nicht mehr stillschweigend fehlschlagen – damit ich eine gewisse Vorwarnung habe. Dachte nur, Sie würden es wissen wollen!

4 „Gefällt mir“