Eine Website sendet sofort ein Jahr HSTS samt includeSubDomains. Kurz darauf sind ein älterer Staging-Host und ein Mail-Dienst im Browser nicht mehr erreichbar, weil beide noch kein funktionierendes HTTPS anbieten.
HSTS ist eine wirksame Browserrichtlinie, aber kein Reparaturwerkzeug für SSL. Vor der Aktivierung müssen Zertifikate, Weiterleitungen und Erneuerung bereits zuverlässig funktionieren. Der sichere Weg beginnt mit einem kurzen max-ageund erweitert den Geltungsbereich erst nach gründlicher Beobachtung.
- Was das Thema bedeutet
- Ein realistisches WordPress-Beispiel
- Warum es wichtig ist und wann es eingesetzt wird
- Der einfache Weg für Einsteiger
- Der technische Weg
- Risiken, häufige Fehler, Backup und Rollback
- Wie AIOWS unterstützt: AIOWS SSL Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Was HSTS bewirkt
HTTP Strict Transport Security weist unterstützte Browser an, einen Host während der gespeicherten Laufzeit ausschließlich per HTTPS aufzurufen. Nach dem ersten gültigen HTTPS-Kontakt ersetzt der Browser auch manuell eingegebene HTTP-Adressen lokal durch HTTPS.
includeSubDomainsdehnt die Richtlinie auf alle darunterliegenden Hostnamen aus. Die Preload-Liste geht weiter: Teilnehmende Browser kennen die Richtlinie bereits vor dem ersten Besuch. Weder HSTS noch Preload installiert ein Zertifikat oder behebt eine fehlerhafte HTTPS-Konfiguration.
Ein realistisches WordPress-Beispiel
Die Hauptwebsite und wwwfunktionieren über HTTPS. Unter legacy.example.comläuft jedoch noch ein Dienst ohne gültiges Zertifikat. Wird auf der Hauptdomain HSTS mit includeSubDomainsund langer Laufzeit gesendet, verweigern wiederkehrende Browser den unverschlüsselten Zugriff auf den alten Dienst.
Das Team entfernt die breite Richtlinie, soweit sie serverseitig noch steuerbar ist, und wartet die bereits gespeicherte Laufzeit ab. Danach werden alle Subdomains inventarisiert, HTTPS-Lücken geschlossen und HSTS zunächst nur für die Hauptdomain mit kurzer Laufzeit eingeführt.
Warum eine stufenweise Einführung wichtig ist
HSTS verhindert Downgrade-Versuche und reduziert das Risiko, dass Besucher versehentlich über HTTP beginnen. Gleichzeitig kann eine lange oder zu breite Richtlinie einen Zertifikatsfehler in einen anhaltenden Ausfall verwandeln, weil der Browser keinen HTTP-Rückweg mehr zulässt.
Aktivieren Sie HSTS erst, wenn Hauptdomain, www, Login, API, Downloads und alle vorgesehenen Subdomains dauerhaft per HTTPS erreichbar sind. Die automatische Zertifikatserneuerung muss ebenfalls nachweislich funktionieren.
Der einfache Weg für Einsteiger
- Prüfen Sie jede öffentliche Domain und Subdomain über HTTPS.
- Bestimmen Sie genau eine Ebene, die den HSTS-Header setzt.
- Beginnen Sie ohne
includeSubDomainsund mit einem kurzenmax-age. - Testen Sie HTTP-Eingaben, Login, Formulare, APIs, Downloads und Zertifikatserneuerung.
- Erhöhen Sie die Laufzeit schrittweise, wenn der Betrieb stabil bleibt.
- Aktivieren Sie
includeSubDomainsoder Preload nur nach einer gesonderten Freigabe.
Der technische Weg
Erstellen Sie ein Host-Inventar mit HTTPS-Status, Zertifikatsabdeckung, Erneuerungsweg und zuständigem Team. Prüfen Sie den Header auf ungecachten Antworten am öffentlichen Endpunkt sowie – falls relevant – am Ursprung. Doppelte Header aus CDN und Webserver müssen vermieden werden.
- Dokumentieren Sie den aktuellen
max-ageund den Zeitpunkt jeder Erhöhung. - Kontrollieren Sie Fehlerseiten und Redirects, nicht nur erfolgreiche Seitenaufrufe.
- Berücksichtigen Sie delegierte oder von Drittanbietern betriebene Subdomains.
- Planen Sie einen serverseitigen Notfallzugang, auch wenn bereits gespeicherte Browserrichtlinien nicht sofort rückgängig werden.
Risiken, häufige Fehler, Backup und Rollback
Das Entfernen des Headers löscht eine bereits im Browser gespeicherte Richtlinie nicht sofort. Deshalb ist ein Rollback bei kurzer Laufzeit erheblich einfacher. Besonders riskant sind ein sofortiges Jahresintervall, ungeprüftes includeSubDomainsund eine Preload-Anmeldung ohne vollständige Hostkontrolle.
- Sichern Sie die bestehende CDN-, Proxy- oder Webserver-Konfiguration.
- Ändern Sie nicht gleichzeitig Zertifikat, Redirect und HSTS-Umfang.
- Stoppen Sie bei Namensfehlern, abgelaufenen Zertifikaten oder Redirect-Schleifen.
- Verlängern Sie die Laufzeit erst nach einem realen Erneuerungszyklus.
Wie AIOWS unterstützt:
AIOWS SSL Manager
AIOWS SSL Manager unterstützt die WordPress-seitige Prüfung des HTTPS-Zustands, die einer HSTS-Einführung vorausgehen sollte. Damit können Sie relevante sichere Adressen und unterstützte SSL-Einstellungen zentral nachvollziehen, bevor eine Browserrichtlinie den Rückweg über HTTP sperrt.
Prüfen Sie zunächst außerhalb von WordPress jeden öffentlichen Host, die Zertifikatskette und die automatische Erneuerung. Anschließend kontrollieren Sie mit SSL Manager, ob WordPress konsistente HTTPS-Adressen verwendet und ob Startseite, Login, Administration, Medien, REST und Formulare sicher erreichbar sind. Falls der HSTS-Header in Ihrer Architektur auf CDN- oder Webserverebene gesetzt wird, bleibt diese Konfiguration dort verantwortlich; vermeiden Sie eine zweite, widersprüchliche Quelle.
AIOWS kann eine bereits im Browser gespeicherte HSTS-Richtlinie nicht sofort löschen und keine nicht von WordPress verwaltete Subdomain HTTPS-fähig machen. Deshalb müssen Laufzeit und Umfang konservativ gewählt werden. Halten Sie die vorherige Server- oder CDN-Regel für den Rollback bereit und dokumentieren Sie jede Erhöhung des max-age. Wenn ein Host, Login oder Callback nach einer Änderung ausfällt, entfernen Sie die neue Richtlinie am verantwortlichen Endpunkt und beheben zuerst das HTTPS-Problem. includeSubDomainsund Preload folgen erst, wenn alle abhängigen Hosts dauerhaft abgesichert sind.
Passende AIOWS-Artikel
- HSTS Preload für WordPress: Vorteile und Risiken
- HTTP mit .htaccess auf HTTPS in WordPress umleiten
- WordPress-SSL-Zertifikat und HTTPS-Status prüfen
Fazit und empfohlener Weg
Führen Sie HSTS erst nach vollständiger HTTPS-Prüfung ein. Starten Sie mit kurzer Laufzeit und engem Umfang; includeSubDomainsund Preload sind erst sinnvoll, wenn jeder betroffene Host dauerhaft sicher betrieben und erneuert werden kann.
