HSTS Preload verhindert, dass ein Browser beim ersten Besuch überhaupt eine unverschlüsselte Verbindung versucht. Der Vorteil ist groß – ebenso die Verpflichtung: Nach der Aufnahme erwarten teilnehmende Browser für die registrierte Domain und ihre Subdomains durchgehend funktionierendes HTTPS.
Eine Einreichung sollte deshalb keine Reaktion auf einen Audit-Score sein. Sie ist eine langfristige Betriebsentscheidung für den gesamten Domainraum. Dieser Artikel zeigt, welche technischen und organisatorischen Voraussetzungen vorliegen müssen.
- 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 Preload bedeutet
Bei normalem HSTS erfährt der Browser die Richtlinie erst durch eine HTTPS-Antwort. In einer Preload-Liste ist sie bereits im Browser hinterlegt. Dadurch wird auch der erste Aufruf auf HTTPS umgestellt, bevor eine Netzwerkantwort erfolgt.
Für die Aufnahme verlangt der Preload-Dienst unter anderem einen ausreichend langen max-age, includeSubDomainsund die Direktive preload. Damit müssen auch heutige und künftige Subdomains per HTTPS funktionieren. Eine spätere Entfernung ist möglich, erreicht Nutzer aber erst mit aktualisierten Browserlisten.
Ein realistisches WordPress-Beispiel
Ein Unternehmen reicht example.comein. Kurz danach stellt sich heraus, dass support.example.coman einen externen Anbieter delegiert ist, der kein passendes HTTPS bereitstellt. Für Browser mit aktualisierter Preload-Liste ist der Dienst nicht mehr erreichbar; ein HTTP-Fallback existiert nicht.
Das Problem hätte ein vollständiges DNS- und Zuständigkeitsinventar vor der Einreichung sichtbar gemacht. Nun muss der Dienst HTTPS-fähig werden oder auf einen anderen Namen umziehen, während parallel die Entfernung aus der Liste beantragt wird.
Wann Preload sinnvoll ist
Preload bietet den stärksten Schutz vor einem ersten unsicheren Aufruf und eignet sich für Organisationen, die ihren gesamten Domainraum dauerhaft kontrollieren. Das betrifft nicht nur WordPress, sondern auch Mail-Weboberflächen, Statusseiten, alte Kampagnenhosts und von Partnern betriebene Subdomains.
Verzichten Sie vorerst auf Preload, wenn Subdomains unbekannt sind, Zertifikate manuell erneuert werden oder Drittanbieter keine verbindliche HTTPS-Zusage geben. Solides HSTS im kontrollierten Umfang ist dann die bessere Wahl.
Der einfache Weg für Einsteiger
- Betreiben Sie HSTS zunächst längere Zeit ohne Preload.
- Inventarisieren Sie alle DNS-Namen und delegierten Subdomains.
- Prüfen Sie Zertifikat, Weiterleitung und automatische Erneuerung für jeden aktiven Host.
- Bestätigen Sie, dass
includeSubDomainsbereits ohne Ausfälle funktioniert. - Legen Sie eine dauerhafte organisatorische Zuständigkeit und einen Notfallplan fest.
- Nutzen Sie erst dann die technische Prüfung und Einreichung des Preload-Dienstes.
Der technische Weg
Verbinden Sie DNS-Inventar, Zertifikatsmonitoring und Verantwortlichkeiten in einer gemeinsamen Liste. Erfassen Sie pro Host Betreiber, HTTPS-Status, Aussteller, Erneuerungsweg, Ablaufwarnung und vertragliche Abhängigkeiten. Überwachen Sie neue DNS-Einträge, damit spätere Projekte die Domainpflicht nicht übersehen.
- Prüfen Sie verschachtelte Subdomains und Wildcard-Grenzen.
- Testen Sie Fehlerseiten, Redirects und selten genutzte Dienste.
- Dokumentieren Sie den aktuellen Preload-Status und den Einreichungszeitpunkt.
- Bereiten Sie den offiziellen Entfernungsprozess vor, ohne ihn als schnellen Rollback einzuplanen.
Risiken, häufige Fehler, Backup und Rollback
Die größte Gefahr ist ein unbekannter oder künftiger Subhost ohne HTTPS. Auch eine abgelaufene Zertifikatsautomatik wird nach Preload sofort zum harten Ausfall. Das Entfernen der Direktive oder ein Antrag auf Löschung aus der Liste wirkt nicht unmittelbar auf bereits ausgelieferte Browser.
- Reichen Sie nicht allein für eine bessere Sicherheitsbewertung ein.
- Behandeln Sie Änderungen am Domainraum als freigabepflichtig.
- Testen Sie die Wiederherstellung eines Zertifikats und eines ausgefallenen Endpunkts.
- Stoppen Sie, wenn irgendeine betroffene Subdomain nicht dauerhaft abgesichert ist.
Wie AIOWS unterstützt:
AIOWS SSL Manager
AIOWS SSL Manager unterstützt die WordPress-seitige HTTPS-Prüfung, die Teil der Preload-Vorbereitung ist. Sie können damit nachvollziehen, ob WordPress die erwarteten sicheren Adressen verwendet und ob zentrale Anwendungswege zuverlässig über HTTPS funktionieren.
Die Entscheidung für Preload reicht jedoch weit über WordPress hinaus. Prüfen Sie zuerst den gesamten Domainraum, einschließlich delegierter DNS-Zonen und fremd betriebener Subdomains. Für die WordPress-Website kontrollieren Sie anschließend Startseite, Login, Administration, Medien, REST, Formulare und Callbacks. Wenn HSTS an CDN oder Webserver gesetzt wird, bleibt diese Ebene für den Header verantwortlich; AIOWS sollte nicht als zweite, widersprüchliche Quelle eingesetzt werden.
SSL Manager kann keine Domain in die Browserliste eintragen oder daraus entfernen und garantiert kein HTTPS für externe Dienste. Nutzen Sie das Modul daher zur WordPress-seitigen Bestandsaufnahme, nicht als alleinige Freigabe für Preload. Vor der Einreichung müssen Zertifikatserneuerung, Monitoring und organisatorische Zuständigkeit unabhängig belegt sein. Ein klassischer Rollback ist nach der Aufnahme nicht kurzfristig möglich. Bei Unsicherheit betreiben Sie HSTS weiterhin ohne Preload und mit einem Umfang, den Ihr Team vollständig kontrolliert.
Passende AIOWS-Artikel
- HSTS in WordPress sicher und schrittweise aktivieren
- WordPress-SSL-Zertifikat und HTTPS-Status prüfen
- HTTPS-Canonical-URLs und Sitemaps in WordPress
Fazit und empfohlener Weg
Wählen Sie HSTS Preload nur bei reifer, domainweiter HTTPS-Steuerung. Sind Inventar, Erneuerung oder Zuständigkeit noch lückenhaft, betreiben Sie HSTS im kontrollierten Umfang zuverlässig und lassen die Preload-Liste unverändert.
