Fügen Sie den HSTS-Header am HTTPS-Endpunkt für Nextcloud hinzu.

Die „Strict-Transport-Security“-Warnung von Nextcloud bedeutet, dass die Prüfung keinen HSTS-Header mit einer Gültigkeitsdauer max-agevon mindestens 15552000180 Sekunden (180 Tagen) in der öffentlichen HTTPS-Antwort gefunden hat. Fügen Sie den Header auf dem Webserver oder Reverse-Proxy hinzu, der HTTPS bereitstellt, und testen Sie anschließend die entsprechende öffentliche URL. HSTS ist keine Einstellung in Nextcloud config.php, und eine einfache HTTP-Antwort kann keine HSTS-Richtlinie im Browser festlegen.

Was vor einer Konfigurationsänderung zu prüfen ist

• Prüfen Sie, ob die Nextcloud-Website korrekt über HTTPS geladen wird und ein gültiges Zertifikat für ihren Hostnamen vorlegt.
• Ermitteln Sie, welcher Dienst TLS beendet: Apache, NGINX, ein Load Balancer, ein Container-Ingress oder ein externer Proxy.
• Prüfen Sie, ob dieser Dienst bereits eine entsprechende Richtlinie festgelegt hat Strict-Transport-Security. Senden Sie eine eindeutige Richtlinie vom öffentlichen TLS-Endpunkt; doppelte oder widersprüchliche Header erschweren die Überprüfung.
• Prüfen Sie, ob alle Subdomains für HTTPS bereit sind, bevor Sie die Option hinzufügen includeSubDomains. Aktivieren Sie die Option nicht, preloadum diese Warnung schnell zu beheben.

HSTS weist Browser an, dass zukünftige Verbindungen zu einem Hostnamen HTTPS verwenden müssen. Dadurch wird verhindert, dass ein Browser nach Erhalt der Richtlinie auf HTTP zurückgreift. HSTS ersetzt jedoch weder TLS noch behebt es ein ungültiges Zertifikat oder leitet den ersten HTTP-Besuch um; eine separate HTTP-zu-HTTPS-Weiterleitung muss zusätzlich konfiguriert werden. Das Administrationshandbuch von Nextcloud 35 gibt den Mindestwert von 15552000 Sekunden an und empfiehlt, den Header auf dem Webserver zu setzen. Die eigentliche Durchsetzung der Richtlinie in einer Proxy-Umgebung erfolgt durch die Komponente, die die Antwort an den Besucher zurücksendet.

Legen Sie eine Basisrichtlinie fest

Eine konservative Ausgangsrichtlinie für einen Nextcloud-Hostnamen lautet:

Strict-Transport-Security: max-age=15552000

Dies erfüllt die Mindestlebensdauer von Nextcloud-Dokumenten, ohne die Richtlinie automatisch auf jede Subdomain anzuwenden. Sobald Sie sichergestellt haben, dass alle relevanten Subdomains HTTPS dauerhaft unterstützen, können Sie die Richtlinie hinzufügen ; includeSubDomains. Ein Browser, der diese Direktive gelernt hat, erfordert HTTPS auch für diese Subdomains. Ein internes Dashboard, ein E-Mail-Dienst oder ein älterer Dienst, der noch auf HTTP basiert, kann in diesem Browser nicht mehr erreichbar sein, bis er migriert wurde oder die Richtlinie abläuft.

Apache

Bei einem Apache TLS Virtual Host muss mod_headersdie Direktive im HTTPS Virtual Host aktiviert und platziert werden, nicht nur im Port 80 Redirect Host:

<VirtualHost *:443>
    ServerName cloud.example.com
    # Keep the existing TLS and Nextcloud configuration here.
    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=15552000"
    </IfModule>
</VirtualHost>

Ersetzen Sie den Beispiel-Hostnamen und behalten Sie Ihr bestehendes Zertifikat sowie Ihre Proxy- oder PHP-Konfiguration bei. Das Apache-Härtungsbeispiel von Nextcloud verwendet Header always seteinen HTTPS-Virtual-Host. Überprüfen Sie die Apache-Konfiguration mit dem von Ihrer Distribution unterstützten Befehl `config-test` und laden Sie Apache nur dann neu, wenn der Test erfolgreich ist.

NGINX

Fügen Sie in NGINX den Header innerhalb des serverBlocks hinzu, der auf HTTPS unter dem öffentlichen Nextcloud-Hostnamen lauscht:

server {
    listen 443 ssl;
    server_name cloud.example.com;
    # Keep your existing TLS and Nextcloud locations here.
    add_header Strict-Transport-Security "max-age=15552000" always;
}

Diese Konfiguration darf nicht als vollständiger Ersatz für die bestehende Serverkonfiguration verwendet werden. Die Header-Vererbung in NGINX kann davon abhängen, ob ein verschachtelter Speicherort eigene add_headerDirektiven definiert. Überprüfen Sie daher die effektive Konfiguration und testen Sie repräsentative Antworten, einschließlich statischer Ressourcen und DAV-Endpunkte. Das offizielle Nextcloud-NGINX-Beispiel enthält eine HSTS-Einstellung in seiner HTTPS-Konfiguration und weist Administratoren darauf hin, das Vorladen nicht zu aktivieren.

Reverse-Proxy oder Ingress

Wenn ein Load Balancer, Ingress oder gehosteter Proxy HTTPS beendet, bevor der Datenverkehr an Nextcloud weitergeleitet wird, konfigurieren Sie HSTS auf dieser öffentlichen TLS-Ebene, es sei denn, Ihre Architektur fügt es bewusst auf einer vertrauenswürdigen Upstream-Ebene hinzu. Ein Header, der nur vom Backend hinzugefügt wird, kann vom Proxy entfernt oder ersetzt werden. Umgekehrt kann die Konfiguration auf beiden Ebenen zu doppelten Werten führen. Überprüfen Sie die Antwortheader-Konfiguration des Proxys und stellen Sie sicher, dass die HTTPS-Route die zu testende ist. Halten Sie die Einstellungen für den vertrauenswürdigen Proxy und die HTTPS-URL von Nextcloud konsistent mit der bestehenden Bereitstellung, aber verwenden Sie diese Einstellungen nicht als Ersatz für das Senden des Headers.

Überprüfen Sie die öffentliche Reaktion

1. Verwenden Sie den Syntaxprüfer der Plattform für die geänderte Webserver- oder Proxy-Konfiguration.
2. Die validierte Konfiguration neu laden oder bereitstellen.
3. Fordern Sie die öffentliche HTTPS-Adresse an und überprüfen Sie die Antwortheader: curl -sSI https://cloud.example.com/. Suchen Sie nach einer Strict-Transport-SecurityZeile, deren max-ageWert mindestens 15552000.
4. Überprüfen Sie in den Entwicklertools Ihres Browsers die Antwort vom selben öffentlichen Hostnamen. Dadurch lässt sich ein Proxy aufdecken, der die Header verändert, oder eine Route, die den erwarteten virtuellen Host umgeht.
5. Laden Sie die Seite „Administration → Übersicht“ von Nextcloud neu und warten Sie, bis die Sicherheitsprüfung aktualisiert ist.

Wird curlkein HSTS-Header angezeigt, überprüfen Sie, ob der DNS-Eintrag auf den bearbeiteten Endpunkt verweist, ob die Anfrage HTTPS verwendet und ob der Proxy den Header nicht entfernt. Erscheint der Header auf der Startseite, aber nicht in anderen Antworten, überprüfen Sie die NGINX-Location-Direktiven oder die Proxy-Antwortheader-Regeln. Ist die öffentliche Antwort korrekt, Nextcloud gibt aber weiterhin eine Warnung aus, stellen Sie sicher, dass die Administratorprüfung denselben extern sichtbaren Hostnamen und dasselbe Schema verwendet. Überprüfen Sie anschließend jegliche Caching- oder Proxy-Schichten zwischen Server und Prüfung.

Preload nur nach einer domänenweiten Überprüfung verwenden.

Die Vorladeoption ist eine separate, aber folgenreiche Entscheidung. Die Vorladeoption selbst registriert keine Domain; Browser-Vorladelisten haben eigene Anforderungen für die Registrierung. Aktuelle Browserrichtlinien erfordern eine lange max-ageRegistrierungszeit includeSubDomains. Nextcloud weist darauf hin, dass es Monate dauern kann, bis die Entfernung aus einer ausgelieferten Vorladeliste in allen installierten Browsern wirksam wird. Beginnen Sie mit der Basisrichtlinie, erfassen Sie alle betroffenen Hostnamen, stellen Sie sicher, dass HTTPS in der gesamten Domain funktioniert, und prüfen Sie die offiziellen Vorladeanforderungen, bevor Sie die Vorladeoption anwenden. Die meisten Nextcloud-Administratoren können diese Warnung beheben, ohne die Vorladeoption zu aktivieren.

Referenz: Nextcloud 35 Sicherheitswarnungen , Nextcloud-Härtungshinweise , Nextcloud NGINX-Konfiguration und MDNs HSTS-Header-Referenz .