Das Zertifikat der Website ist gültig, trotzdem erzeugt eine kopierte HTTPS-Regel hinter dem CDN eine Endlosschleife. Der Browser nutzt HTTPS zum CDN, das CDN verbindet sich intern per HTTP mit dem Ursprungsserver. Apache hält deshalb jede Anfrage erneut für unsicher.
Eine richtige HTTPS-Weiterleitung berücksichtigt, wo TLS endet und welcher vertrauenswürdige Wert das ursprünglich vom Besucher verwendete Protokoll beschreibt. Sie ersetzt weder ein Zertifikat noch die Bereinigung unsicher eingebundener Ressourcen.
Was HTTPS erzwingen bedeutet
Eine HTTP-Anfrage wird dauerhaft und direkt zur entsprechenden HTTPS-URL umgeleitet. Host, Pfad und benötigte Query-Parameter bleiben erhalten. Die sichere Zieladresse muss bereits ein gültiges Zertifikat liefern und ohne weitere Protokollweiterleitung antworten.
HTTPS erzwingen beseitigt kein Mixed Content. Fest eingetragene HTTP-URLs in Bildern, Skripten, Stylesheets oder Datenbankwerten werden separat korrigiert. HSTS folgt erst nach stabiler HTTPS-Einführung.
Beispiel hinter einem CDN
Das CDN terminiert TLS und sendet die Anfrage per HTTP zum Origin. Der Hoster dokumentiert einen Forwarded-Header, der nur vom bekannten Proxy gesetzt und vor fremder Eingabe bereinigt wird. Die Serverregel berücksichtigt diesen Wert und leitet nur dann um, wenn die öffentliche Anfrage tatsächlich über HTTP kam.
HTTP über CDN führt nun mit einem Sprung zur endgültigen HTTPS-URL. HTTPS über CDN antwortet direkt. Origin-Zugriffe und Healthchecks werden entsprechend ihrer vorgesehenen Topologie separat getestet.
Voraussetzungen
- Zertifikat und vollständige Zertifikatskette passen zu allen öffentlichen Hosts.
- WordPress-Adresse und Website-Adresse verwenden HTTPS.
- CDN, Load Balancer und Origin haben eine dokumentierte TLS-Topologie.
- Nur vertrauenswürdige Proxyinformationen beeinflussen die Protokollerkennung.
- Keine zweite Ebene erzwingt HTTPS mit widersprüchlicher Logik.
Sichere Einführung
- Sichern Sie die
.htaccessund halten Sie externen Dateizugriff bereit. - Bestätigen Sie HTTPS direkt am öffentlichen Ziel.
- Ermitteln Sie die Ebene, die den Redirect verantwortet.
- Aktivieren Sie eine direkte Regel außerhalb des generierten WordPress-Blocks.
- Testen Sie HTTP und HTTPS für Hostvarianten, Permalinks, Adminbereich, REST, Medien und Formulare.
- Bereinigen Sie Mixed Content und bewerten Sie HSTS erst danach.
Proxy- und Header-Prüfung
Erstellen Sie eine Matrix aus CDN-HTTP, CDN-HTTPS, Origin-HTTP, Origin-HTTPS und erforderlichen Healthchecks. Zeichnen Sie Status und Locationjedes Sprungs auf. Prüfen Sie, welches Protokoll Apache sieht und welcher Proxy den Forwarded-Header setzt.
Ein vom Client frei manipulierbarer Header darf niemals alleinige Wahrheit sein. Testen Sie fehlende, korrekte und absichtlich gefälschte Werte. Die Regel muss eine bereits sicher zugestellte öffentliche Anfrage erkennen, ohne fremde Header zu akzeptieren.
Risiken, Backup und Rollback
Eine Weiterleitung vor Zertifikatsbereitschaft führt Besucher in einen TLS-Fehler. Gestapelte CDN- und Serverregeln erzeugen Ketten; falsches Headervertrauen ermöglicht Protokoll-Spoofing. Aktivieren Sie HSTS nicht während einer ungeklärten Schleife.
Bei einem Ausfall stellen Sie die gesicherte Datei über den unabhängigen Zugang wieder her. Prüfen Sie danach HTTP und HTTPS direkt und über das CDN, bevor Sie Caches verändern oder eine korrigierte Regel erneut einführen.
So unterstützt AIOWS:
AIOWS Htaccess Editor
AIOWS Htaccess Editor unterstützt in geeigneten Apache-kompatiblen Umgebungen die kontrollierte Bearbeitung der .htaccessund sichert die Datei vor dem Speichern. Eine HTTPS-Regel kann dadurch als klar abgegrenzter Abschnitt verwaltet werden, statt unbemerkt im WordPress-Rewrite-Block zu landen.
Belegen Sie zunächst Zertifikat, öffentlichen HTTPS-Zugriff und Proxy-Topologie. Speichern Sie erst dann die eng begrenzte Regel. Unmittelbar danach prüfen Sie alle Host- und Protokollvarianten sowie Anmeldung, REST, Formulare und statische Dateien. Die gespeicherte Datei und die tatsächlich beobachtete Antwort müssen übereinstimmen.
Der Editor stellt keine Zertifikate bereit, konfiguriert kein CDN und entscheidet nicht, welchem Forwarded-Header vertraut werden darf. Entsteht eine Schleife, stellen Sie über den unabhängigen Dateizugang die Vorversion wieder her und korrigieren die Logik an der zuständigen Infrastrukturkomponente.
Passende Artikel
- Mixed Content in WordPress beheben
- HTTPS in WordPress erzwingen, ohne die Website zu beschädigen
- WWW- und Non-WWW-Regeln in der WordPress-.htaccess
Fazit
Stellen Sie zuerst sicher, dass HTTPS und die Proxy-Erkennung zuverlässig funktionieren. Danach genügt eine direkte Weiterleitung an genau einer Ebene; Mixed Content und HSTS werden getrennt behandelt.
