Nach Umstellung auf https kein Login mehr möglich

Hallo,

ich möchte meine WordPress-Installation gern auf HTTPS umstellen und folgte dazu der Anleitung webongo: WordPress auf https umstellen (SSL-Verschlüsselung). Leider bleibe ich bereits bei Schritt 3 hängen.

Vorgehensweise

1. TLS-Zertifikat beschaffen
2. Blog über HTTP und HTTPS erreichbar machen (bei Aufruf über HTTPS, wird wie erwartet vor unsicherem Inhalt gewarnt. Mein Theme wird nicht geladen)
3. Backup von DocumentRoot und MySQL-Datenbank
4. Änderung der Werte von WordPress-Adresse (URL) und Website-Adresse (URL) in den allgemeinen Einstellungen im Backend
5. Übernahme der Änderungen

Nach Schritt 5 wird die Seite neu geladen und läuft in einen Umleitungsfehler. Wie in Schritt 4 der Anleitung beschrieben, habe ich folgende Zeile meiner wp-config.php hinzugefügt:

define( 'WP_CONTENT_URL', 'https://www.my-it-brain.de/wordpress/wp-content' );

Leider kann ich nach diesem Schritt weiterhin nicht auf mein Backend zugreifen, um mit den Anpassungen an der Datenbank weiter zu machen. Daher habe ich alle bisherigen Änderungen durch folgende drei Zeilen in meiner wp-config.php wieder rückgängig gemacht:

define('WP_SITEURL', 'http://www.my-it-brain.de/wordpress');
define('WP_HOME', 'http://www.my-it-brain.de/wordpress');
define('WP_CONTENT_URL','http://www.my-it-brain.de/wordpress/wp-content');

Informationen über meinen Blog

• URL:http://www.my-it-brain.de/wordpress/
• WP-Version: 4.7
• Verwendetes Theme: Twenty Twelve Child (Anpassung: Es werden nur Anreißtexte auf der Startseite gezeigt)
• Verwendete Plugins:
  
  
  • Add From Server (Version: 3.3.2; deaktiviert)
  • Antispam Bee (Version: 2.6.9)
  • Broken Link Checker (Version: 1.11.2)
  • Enable Media Replace (Version: 3.0.5)
  • Fast Secure Contact Form (Version: 4.0.44)
  • FD Footnotes (Version: 1.36)
  • NewStatPress (Version: 1.2.4)
  • Search & Replace (Version: 3.1.2; deaktiviert)
  • Shariff Wrapper (Version: 4.3.0)
  • Statify (Version: 1.4.3; deaktiviert)
  • TablePress (Version: 1.7)
  • WordPress Importer (Version: 0.6.3; deaktiviert)
  • WP Code Highlight (Version: 1.2.9; deaktiviert)
  • WP User Avatar (Version: 2.0.8)
  • WP-Cumulus (Version: 1.23; deaktiviert)
  • WP-Polls (Version: 2.73.2; deaktiviert)

  
  

• Letzte Änderungen: Die oben unter Vorgehensweise beschriebenen

Ich habe die Prozedur inzwischen zweimal durchgespielt, um Flüchtigkeits- bzw. Tippfehler auszuschließen. Jedoch komme ich jedes Mal zum gleichen Ergebnis.

Könnte ihr mir helfen, wie ich hier weitermachen und wo ich nach Fehlern suchen kann? Ich möchte mich gern wieder einloggen, um anschließend das Plugin "Search & Replace" für die Änderungen an der Datenbank zu verwenden. Ich habe in einem dritten durchgeführten Versuch die Änderungen direkt in der Datenbank durchgeführt. Dadurch konnte ich das Problem, mich nicht anmelden zu können, jedoch ebenfalls nicht lösen.

MfG
Hetmann

Guten Morgen,

ich möchte noch ein paar Daten zur Serverumgebung nachreichen:

• Server: Ubuntu 14.04 LTS
• Webserver: Nginx 1.4.6
• PHP: PHP7.0-FPM

Es handelt sich dabei um einen Root-Server, auf den ich vollen Zugriff via SSH habe.

Hallo,

ich habe das "Database Search and Replace Script in PHP" genutzt, um die Änderungen in der Datenbank vorzunehmen. Dabei habe ich allerdings folgende Strings verwendet:

Suchen: http://www.my-it-brain.de

Ersetzen: https://www.my-it-brain.de

Die Umleitung habe ich dann in der vHost-Konfiguration gemacht. Allerdings bleibt das im ersten Beitrag beschriebene Problem bestehen. Ich bekomme beim Aufruf der Loginseite einen Umleitungsfehler und mein Theme wird bei Aufruf über HTTPS nicht (richtig) geladen.

Guten Abend,

nachdem ich meine WordPress-Installation auf Version 4.7.1 aktualisiert habe, habe ich heute einen erneuten Versuch unternommen, meinen Blog auf HTTPS umzustellen.

Die Ausgangssituation ist wie folgt:

1. Ein gültiges TLS-Zertifikat ist vorhanden
2. Der vHost ist für den Zugriff über HTTP und HTTPS konfiguriert
3. Das Backend (wp-login.php) lässt sich über HTTP normal aufrufen

Das Backend (wp-login.php) lässt sich über HTTPS ebenfalls aufrufen, allerdings wird kein CSS geladen. Ich kann mich jedoch anmelden und werde dann auf eine HTTP-URL umgeleitet.

Nun trage ich als erstes folgende Zeilen in meine wp-config.php ein:

define('WP_SITEURL', 'https://www.my-it-brain.de/wordpress');
define('WP_HOME', 'https://www.my-it-brain.de/wordpress');
define('WP_CONTENT_URL','https://www.my-it-brain.de/wordpress/wp-content');

Rufe ich nun die URL https://www.my-it-brain.de/wordpress/wp-login.php auf, erhalte ich einen Umleitungsfehler. Im Error-Log laufen keine Fehlermeldungen auf. Im Access-Log sehe ich, dass folgende Anfrage an meinen Server gesendet wird:

[14/Jan/2017:20:07:09 +0100]  "GET /wordpress/wp-login.php HTTP/1.1" 302 5 "-" "Mozilla/5.0 (X11;  Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0"

Mein Webbrowser erhält folgenden Antwort-Header:

HTTP/1.1 302 Found
Server: nginx/1.4.6 (Ubuntu)
Date: Sat, 14 Jan 2017 19:07:08 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Location: https://www.my-it-brain.de/wordpress/wp-login.php

Ich verstehe nicht, woher die Redirect kommt. Ich habe zu diesem Zeitpunkt ja noch gar keine Umleitung eingerichtet. Gern würde ich verstehen, was hier falsch läuft und wie ich von hier aus sinnvoll weiter mache.

Kann mir jemand dabei behilflich sein und mir einen Tipp geben, was an diesem Punkt zu tun bzw. zu prüfen ist?

MfG
Hetmann

Guten Abend,

mit der Unterstützung meines Lieblings-Entwicklers ist mein Blog nun endlich über HTTPS erreichbar. Die Ursache meines Scheiterns liegt in absoluter Betriebsblindheit. Damit vielleicht auch noch andere aus meinem Scheitern lernen können, möchte ich hier die Ursache und Lösung kurz posten.

In meiner NGINX-vHost-Konfiguration stand folgende Zeile:

fastcgi_param HTTPS off;

Diese führte nach der Änderung der Blog-URL zu einem Umleitungsfehler auf der Seite "wp-login.php". Die Zeile wurde gelöscht und alle Anfragen mit einem 301-Redirect auf HTTPS umgeleitet. Und schon war der Blog unter HTTPS erreichbar.

Gruß

Hetmann