Die öffentliche Website läuft über HTTPS, doch nach dem Absenden des Logins wechselt WordPress hinter einem Reverse Proxy auf HTTP oder gerät in eine Redirect-Schleife. In dieser Situation reicht es nicht, FORCE_SSL_ADMINblind zu aktivieren.
Zuerst müssen das Zertifikat und die kanonische URL stimmen; außerdem muss WordPress zuverlässig erkennen, dass der ursprüngliche Aufruf von außen per HTTPS erfolgte. Danach lässt sich HTTPS für Login und Administration sicher erzwingen, ohne Administratoren auszusperren.
- 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 FORCE_SSL_ADMIN bewirkt
Die WordPress-Konstante FORCE_SSL_ADMINweist WordPress an, Login und Administrationsbereich über HTTPS zu verwenden. Sie installiert kein Zertifikat und repariert keinen Proxy, der HTTPS-Anfragen intern als HTTP meldet.
Hinter einem Reverse Proxy muss WordPress anhand vertrauenswürdig weitergegebener Proxy-Header erkennen, dass der ursprüngliche Aufruf von außen per HTTPS erfolgte. Andernfalls erzeugt die Anwendung falsche Redirects oder setzt Authentifizierungs-Cookies nicht wie erwartet.
Ein realistisches WordPress-Beispiel
Ein Load Balancer terminiert TLS und leitet die Anfrage intern per HTTP an WordPress weiter. Der Header für das ursprüngliche Protokoll ist vorhanden, wird aber in der Serverkonfiguration nicht ausgewertet. WordPress hält die Anfrage deshalb für unsicher und leitet erneut auf HTTPS.
Das Team beschränkt das Vertrauen auf den bekannten Proxy, stellt die HTTPS-Erkennung vor dem WordPress-Start richtig ein und prüft anschließend FORCE_SSL_ADMIN. Login, Dashboard, Logout und Passwort-Reset funktionieren danach ohne Schleife.
Warum Admin-HTTPS besonders wichtig ist
Login und Administration übertragen Zugangsdaten, Nonces und Authentifizierungs-Cookies. Diese Wege dürfen nicht auf HTTP zurückfallen. Eine uneinheitliche Erkennung kann außerdem Sitzungen abbrechen, REST-Anfragen aus dem Backend stören und Multisite- oder Domain-Cookie-Probleme verschärfen.
Erzwingen Sie Admin-HTTPS erst, wenn der öffentliche HTTPS-Endpunkt gültig ist und die WordPress-Adressen zum kanonischen Host passen. Bei einem Proxy muss außerdem belegt sein, dass er das extern verwendete HTTPS-Protokoll korrekt an WordPress weitergibt.
Der einfache Weg für Einsteiger
- Prüfen Sie
https://…/wp-login.phpund/wp-admin/manuell. - Sichern Sie
wp-config.phpund halten Sie einen serverseitigen Dateizugang offen. - Kontrollieren Sie WordPress-Adresse und Website-Adresse.
- Aktivieren Sie
FORCE_SSL_ADMINnur einmal und ohne parallele Redirect-Änderung. - Testen Sie Login, Dashboard, Logout und Passwort-Reset in einem privaten Fenster.
- Prüfen Sie, ob Authentifizierungs-Cookies das Secure-Attribut tragen.
Der technische Weg
Vergleichen Sie das von außen verwendete Protokoll mit der internen Verbindung sowie Proxy-Header, is_ssl()-Ergebnis, home, siteurl, Login-Redirects und Cookie-Attribute. Vertrauen Sie weitergeleiteten Headern nur, wenn die Anfrage nachweislich von einem bekannten Proxy stammt.
- Testen Sie tiefe Admin-Pfade sowie Medien- und Pluginseiten.
- Prüfen Sie REST-Nonce-Anfragen und gegebenenfalls Multisite-Domainmapping.
- Berücksichtigen Sie Session-Affinität bei mehreren Backend-Servern.
- Verwenden Sie einen gefälschten Forwarded-Header als negative Kontrolle.
Risiken, häufige Fehler, Backup und Rollback
Wird Admin-HTTPS vor einem funktionierenden TLS-Endpunkt oder vor korrekter Proxy-Erkennung erzwungen, kann der gesamte Administrationszugang ausfallen. Beliebigen Forwarded-Headern zu vertrauen ist dagegen ein Sicherheitsrisiko, weil Clients den erkannten Zustand manipulieren könnten.
- Ändern Sie nicht gleichzeitig WordPress-URLs, Proxylogik und Redirects.
- Bewahren Sie die vorherige
wp-config.phpauf. - Halten Sie eine zweite Sitzung und einen serverseitigen Notfallzugang bereit.
- Rollen Sie die Konstante zurück, wenn Login oder Passwort-Reset nicht mehr funktioniert.
Wie AIOWS unterstützt:
AIOWS SSL Manager
AIOWS SSL Manager bündelt unterstützte WordPress-seitige HTTPS-Einstellungen und erleichtert damit die Prüfung von Login und Administration. Statt mehrere SSL-Plugins mit eigenen Redirects zu kombinieren, können Sie den relevanten WordPress-Zustand an einer Stelle nachvollziehen.
Prüfen Sie vor jeder Änderung den öffentlichen HTTPS-Aufruf und den kanonischen Host. Hinter einem Reverse Proxy muss außerdem feststehen, wie der Proxy das extern verwendete HTTPS-Protokoll vertrauenswürdig an WordPress weitergibt. Nehmen Sie anschließend nur die benötigte unterstützte Einstellung vor und testen Sie eine ausgeloggte und eine angemeldete Sitzung. Dazu gehören Login, Dashboard, Logout, Passwort-Reset, REST-Anfragen und die Cookie-Attribute.
Der SSL Manager kann kein fehlendes Zertifikat installieren, keinen externen Proxy umkonfigurieren und keine unsichere Header-Vertrauenskette reparieren. Diese Voraussetzungen müssen in der Infrastruktur erfüllt werden. Sichern Sie deshalb die aktuelle Konfiguration und behalten Sie einen unabhängigen Dateizugang. Wenn nach der WordPress-seitigen Änderung eine Schleife oder ein Login-Ausfall auftritt, stellen Sie die vorherige Einstellung wieder her und prüfen zuerst Proxy- und URL-Erkennung. Der gewünschte Endzustand ist ein durchgehend sicherer Admin-Pfad mit stabilen Sitzungen, nicht lediglich ein Schloss-Symbol auf der Loginseite.
Passende AIOWS-Artikel
- Mixed Content in WordPress beheben: HTTPS-Fehler richtig lösen
- HSTS in WordPress sicher und schrittweise aktivieren
- HTTP mit .htaccess auf HTTPS in WordPress umleiten
Fazit und empfohlener Weg
Erzwingen Sie HTTPS für Login und Administration erst, wenn Zertifikat, kanonische URLs und Proxy-Erkennung stimmen. Halten Sie einen Notfallzugang bereit und akzeptieren Sie die Änderung nur bei stabilen sicheren Sitzungen ohne Redirect-Schleife.
