{"id":1974,"date":"2026-08-19T13:30:56","date_gmt":"2026-08-19T10:30:56","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=1974"},"modified":"2026-08-04T11:29:00","modified_gmt":"2026-08-04T11:29:00","slug":"ssl-fuer-wordpress-admin-und-login-erzwingen","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/de\/ssl-fuer-wordpress-admin-und-login-erzwingen\/","title":{"rendered":"HTTPS f\u00fcr WordPress-Admin und Login erzwingen"},"content":{"rendered":"

Die \u00f6ffentliche Website l\u00e4uft \u00fcber HTTPS, doch nach dem Absenden des Logins wechselt WordPress hinter einem Reverse Proxy auf HTTP oder ger\u00e4t in eine Redirect-Schleife. In dieser Situation reicht es nicht, FORCE_SSL_ADMIN<\/code> blind zu aktivieren.<\/p>\n

Zuerst m\u00fcssen das Zertifikat und die kanonische URL stimmen; au\u00dferdem muss WordPress zuverl\u00e4ssig erkennen, dass der urspr\u00fcngliche Aufruf von au\u00dfen per HTTPS erfolgte. Danach l\u00e4sst sich HTTPS f\u00fcr Login und Administration sicher erzwingen, ohne Administratoren auszusperren.<\/p>\n

\nInhaltsverzeichnis<\/strong><\/p>\n
    \n
  1. Was das Thema bedeutet<\/a><\/li>\n
  2. Ein realistisches WordPress-Beispiel<\/a><\/li>\n
  3. Warum es wichtig ist und wann es eingesetzt wird<\/a><\/li>\n
  4. Der einfache Weg f\u00fcr Einsteiger<\/a><\/li>\n
  5. Der technische Weg<\/a><\/li>\n
  6. Risiken, h\u00e4ufige Fehler, Backup und Rollback<\/a><\/li>\n
  7. Wie AIOWS unterst\u00fctzt: AIOWS SSL Manager<\/a><\/li>\n
  8. Passende AIOWS-Artikel<\/a><\/li>\n
  9. Fazit und empfohlener Weg<\/a><\/li>\n
  10. Offizielle Quellen<\/a><\/li>\n<\/ol>\n<\/div>\n

    Was FORCE_SSL_ADMIN bewirkt<\/h2>\n

    Die WordPress-Konstante FORCE_SSL_ADMIN<\/code> weist WordPress an, Login und Administrationsbereich \u00fcber HTTPS zu verwenden. Sie installiert kein Zertifikat und repariert keinen Proxy, der HTTPS-Anfragen intern als HTTP meldet.<\/p>\n

    Hinter einem Reverse Proxy muss WordPress anhand vertrauensw\u00fcrdig weitergegebener Proxy-Header erkennen, dass der urspr\u00fcngliche Aufruf von au\u00dfen per HTTPS erfolgte. Andernfalls erzeugt die Anwendung falsche Redirects oder setzt Authentifizierungs-Cookies nicht wie erwartet.<\/p>\n

    Ein realistisches WordPress-Beispiel<\/h2>\n

    Ein Load Balancer terminiert TLS und leitet die Anfrage intern per HTTP an WordPress weiter. Der Header f\u00fcr das urspr\u00fcngliche Protokoll ist vorhanden, wird aber in der Serverkonfiguration nicht ausgewertet. WordPress h\u00e4lt die Anfrage deshalb f\u00fcr unsicher und leitet erneut auf HTTPS.<\/p>\n

    Das Team beschr\u00e4nkt das Vertrauen auf den bekannten Proxy, stellt die HTTPS-Erkennung vor dem WordPress-Start richtig ein und pr\u00fcft anschlie\u00dfend FORCE_SSL_ADMIN<\/code>. Login, Dashboard, Logout und Passwort-Reset funktionieren danach ohne Schleife.<\/p>\n

    Warum Admin-HTTPS besonders wichtig ist<\/h2>\n

    Login und Administration \u00fcbertragen Zugangsdaten, Nonces und Authentifizierungs-Cookies. Diese Wege d\u00fcrfen nicht auf HTTP zur\u00fcckfallen. Eine uneinheitliche Erkennung kann au\u00dferdem Sitzungen abbrechen, REST-Anfragen aus dem Backend st\u00f6ren und Multisite- oder Domain-Cookie-Probleme versch\u00e4rfen.<\/p>\n

    Erzwingen Sie Admin-HTTPS erst, wenn der \u00f6ffentliche HTTPS-Endpunkt g\u00fcltig ist und die WordPress-Adressen zum kanonischen Host passen. Bei einem Proxy muss au\u00dferdem belegt sein, dass er das extern verwendete HTTPS-Protokoll korrekt an WordPress weitergibt.<\/p>\n

    Der einfache Weg f\u00fcr Einsteiger<\/h2>\n
      \n
    1. Pr\u00fcfen Sie https:\/\/\u2026\/wp-login.php<\/code> und \/wp-admin\/<\/code> manuell.<\/li>\n
    2. Sichern Sie wp-config.php<\/code> und halten Sie einen serverseitigen Dateizugang offen.<\/li>\n
    3. Kontrollieren Sie WordPress-Adresse und Website-Adresse.<\/li>\n
    4. Aktivieren Sie FORCE_SSL_ADMIN<\/code> nur einmal und ohne parallele Redirect-\u00c4nderung.<\/li>\n
    5. Testen Sie Login, Dashboard, Logout und Passwort-Reset in einem privaten Fenster.<\/li>\n
    6. Pr\u00fcfen Sie, ob Authentifizierungs-Cookies das Secure-Attribut tragen.<\/li>\n<\/ol>\n

      Der technische Weg<\/h2>\n

      Vergleichen Sie das von au\u00dfen verwendete Protokoll mit der internen Verbindung sowie Proxy-Header, is_ssl()<\/code>-Ergebnis, home<\/code>, siteurl<\/code>, Login-Redirects und Cookie-Attribute. Vertrauen Sie weitergeleiteten Headern nur, wenn die Anfrage nachweislich von einem bekannten Proxy stammt.<\/p>\n